docs: record the responsive fix and how to re-verify it

The tab harness cannot reproduce this (no rendering means panes_to_hide is
always empty), so the verification is a scripted pty that resizes mid-session.
Written down so it can be re-run rather than re-derived.

1 files changed, 17 insertions, 37 deletions

diff --git a/docs/roadmap.md b/docs/roadmap.md
index c260a5d..bc8aa6f 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -193,47 +193,27 @@ The fork bug is still there for anyone calling `zellij attach -b`, and the next
 step is to instrument `ScreenInstruction::RemoveClient` on a debug build to find
 why the removal never reaches `screen.connected_clients`.
 
-## Known issue: panes stack after a responsive collapse/expand cycle
+## Fixed: panes stacked after a responsive collapse/expand cycle
 
-Reported as "a new pane starts collapsed even though the terminal is big
-enough", and it self-corrects after resizing the window.
+A pane added after a narrow->wide cycle was absorbed into a stack at full width.
+The expand had never actually happened: `SwapLayouts::tiled_layout_at` checked
+whether a layout fits by positioning it against `visible_panes_count()`, and a
+stack hides all its members but one, so a layout with no room for the hidden
+panes passed as feasible. Fixed by checking against every tiled pane.
 
-Reproduced deterministically on the test box (`responsive_min_cols 90`):
+**How to re-run the check** (the tab test harness cannot express this -- it does
+no rendering, so `panes_to_hide` is always empty and both counts are equal):
 
-| sequence | result |
-|---|---|
-| create the session **wide** (160 cols), add a pane | correct 22/22 split |
-| create it **narrow** (80), widen to 160, add a pane | **stacked** at 160 cols |
-
-Instrumented, the second sequence goes:
-
-| step | active swap layout | cols | panes |
-|---|---|---|---|
-| narrow, 1 pane | `None` | 80 | 1 |
-| narrow, +pane | `sl0p:responsive-collapse` | 80 | 1 |
-| widened | `sl0p:responsive-expand` | 160 | 2 |
-| wide, +pane | `sl0p:responsive-expand` | 160 | 3 |
-
-Both the collapse and the expand are correct. The damage is done afterwards: the
-tab stays pinned to the **synthesized** `sl0p:responsive-expand` layout, which
-was generated for the pane count at the time it was synthesized. Add a pane and
-that layout no longer describes the tab, so the extra pane is absorbed into a
-stack — geometry shows two panes sharing `y=0` while a third sits at `y=22`.
-
-`apply_responsive_layout` has exactly one caller (the whole-tab resize path) and
-returns early when already on the correct side of the threshold, so a pane
-count change never re-resolves the synthesized layout. Resizing the window is
-what re-runs it, which is why a resize "fixes" it.
-
-Likely fix: when the pane count changes and the active tiled layout is one of
-the synthesized responsive ones, re-synthesize it for the new count (or drop
-back to BASE when above the threshold). That is the same class of problem as
-`sl0p: keep expanding possible after the pane count changes`, so the existing
-tests around it are the place to start.
+```bash
+# a pty that starts narrow and widens mid-session
+python3 resz.py 80 24 160 45 30 sl0ppi     # see the commit for the script
+sl0ppij -s dev action new-pane
+sl0ppij -s dev action list-panes --json    # compare (x, y, cols, rows) per pane
+```
 
-Deliberately not fixed in the same session it was found: this is the most
-delicate part of the fork, and two quick fixes earlier in this session each
-looked right and turned out to be wrong under verification.
+Two panes sharing one rect means a stack; distinct rects mean it really
+expanded. Check both directions (create narrow then widen, create wide then
+narrow) and add panes afterwards.
 
 ## Standing risks