# resizableWindow behaviour

*Open when authoring a two-pane split with a draggable divider — before you decide the pane sizes or wire the panes' own layout.*

The panes are ordinary children attached through `layout[bp].parentId`; nothing on this side seeds them. Child index 0 is the fixed/collapsing pane and index 1 fills, swapped by `isReverse`. A THIRD child is not a third pane: `getChildLayoutStyle` pins index 0 and fills index 1, and everything after falls through to plain flex sizing with no divider.

**A pane cannot size itself.** `controlsChildSizing` is true — the window writes the fixed pane's size/min/max and stretches the other, so the width or height you set on the pane container is discarded.

**`defaultSize` is clamped by bounds you did not write.** Absent `minSize`/`maxSize` fall back to 150px/600px (`DEFAULTS`, ResizableWindowRuntime.ts:136) and the fixed pane is rendered with size, min and max together. Nothing reports the conflict:

```jsonc
{ "type": "resizableWindow", "defaultSize": "800px" }   // paints at 600px
{ "type": "resizableWindow", "defaultSize": "800px", "maxSize": "900px" }  // paints at 800px
```

A `%` default is not reconciled at author time either — `'40%'` renders as CSS `min(40%, 600px)` and caps on a wide screen.

**Preview lies about size and about the drawer.** Per-user memory (`rememberState`, default true) is read only in the deployed runtime; the builder and its preview always paint `defaultSize`. So an edited `defaultSize` looks applied in preview while a returning user still gets the size they once dragged. `overlayMode` is likewise inert in the builder (both panes stay side by side as drop targets) and needs `collapsible: true` plus horizontal orientation in a live form.

A `visible` condition that hides one pane at runtime leaves a lone pane: `flex: 1 1 0`, no divider, sizing discarded. The authored-child count still reads two, so the gate stays quiet.