feat: add creation-time new-pane visual-stability acceptance tests #101

New issue

Closed

opened 2026-04-28 01:57:45 +00:00 by barrettruth · 0 comments

barrettruth commented

2026-04-28 01:57:45 +00:00

Problem

Issue #100 established that explicit managed new-pane can visibly flash through the wrong intermediate split before relayout. The current test suite mainly validates final pane order, ownership, and final layout state. It does not clearly encode the creation-time bar we now care about: correct first branch, acceptable local resizing, and known unavoidable residual cases.

Proposed solution

Add focused integration coverage and helper vocabulary for creation-time visual stability. The goal is to let follow-up issues test for:

wrong-branch births, which should be treated as failures
acceptable same-branch local resizing after birth
local role-shift cases that may remain partially visible
true global-repartition cases where one exact first split does not exist
zoom/focus-only cases like monocle
min-size failure fallback behavior

Seed the suite with the repro from #100 and at least one example for each residual class that the layout matrix currently identifies.

Context

This is the groundwork issue for the rest of the explicit new-pane follow-up work. Without it, later layout-by-layout fixes will be hard to specify and easy to regress.

Acceptance notes

Agents should be able to express “the pane must be born into the correct broad branch first” without overfitting to 1-cell rounding.
The new helpers should make it practical to add tests per layout family as fixes land.
Keep implementation scope limited to harness and assertion support unless a tiny hook is necessary to observe the state we need.

Alternatives considered

Keep relying on final-layout tests only. That leaves the visual problem under-specified.
Treat creation-time behavior as manual QA. That is not enough for the number of layout/state transitions involved.

## Problem Issue #100 established that explicit managed `new-pane` can visibly flash through the wrong intermediate split before relayout. The current test suite mainly validates final pane order, ownership, and final layout state. It does not clearly encode the creation-time bar we now care about: correct first branch, acceptable local resizing, and known unavoidable residual cases. ## Proposed solution Add focused integration coverage and helper vocabulary for creation-time visual stability. The goal is to let follow-up issues test for: - wrong-branch births, which should be treated as failures - acceptable same-branch local resizing after birth - local role-shift cases that may remain partially visible - true global-repartition cases where one exact first split does not exist - zoom/focus-only cases like monocle - min-size failure fallback behavior Seed the suite with the repro from #100 and at least one example for each residual class that the layout matrix currently identifies. ## Context This is the groundwork issue for the rest of the explicit `new-pane` follow-up work. Without it, later layout-by-layout fixes will be hard to specify and easy to regress. ## Acceptance notes - Agents should be able to express “the pane must be born into the correct broad branch first” without overfitting to 1-cell rounding. - The new helpers should make it practical to add tests per layout family as fixes land. - Keep implementation scope limited to harness and assertion support unless a tiny hook is necessary to observe the state we need. ## Alternatives considered - Keep relying on final-layout tests only. That leaves the visual problem under-specified. - Treat creation-time behavior as manual QA. That is not enough for the number of layout/state transitions involved.