Follow-up from the #40 detail-panel review (Copilot notes on model.go:211 and model.go:329).
Context
decideOutput enforces a 120x24 minimum at startup for both auto and --output tui (since 66a4df7), so the TUI never starts below the floor. That makes the broken-layout edge cases unreachable from startup:
visibleRows() hitting 0 (table non-navigable while the detail panel is open)- the detail-panel placeholder line overflowing
m.width and wrapping, pushing View() past its fixed height
The gap
The gate only runs once, at startup. If the user resizes the terminal below 120x24 while the TUI is already running, a small WindowSizeMsg flows into the model and the same layout breakage becomes reachable. This is a degenerate case (and it affects the whole layout, not just the detail panel), so it was intentionally split out of #40 rather than fixed there.
Options to consider
- Clamp defensively so
visibleRows() never goes below a sane floor and the placeholder/body lines are always width-fit (truncate/pad), so a too-small frame degrades gracefully instead of corrupting.
- Or render a "terminal too small — resize to at least 120x24" placeholder frame while below the floor, and restore the normal view once it grows back.
- Decide which is the better UX; either way the invariant is "the TUI never paints a broken frame."
Follow-up from the TUI work under #32 (#40), but deferred out of the v0.2.0 scope: the startup gate keeps this unreachable on launch, so it does not block #32. Scheduled for the v0.5.0 production-readiness / hardening pass.
Follow-up from the #40 detail-panel review (Copilot notes on
model.go:211andmodel.go:329).Context
decideOutputenforces a 120x24 minimum at startup for bothautoand--output tui(since 66a4df7), so the TUI never starts below the floor. That makes the broken-layout edge cases unreachable from startup:visibleRows()hitting0(table non-navigable while the detail panel is open)m.widthand wrapping, pushingView()past its fixed heightThe gap
The gate only runs once, at startup. If the user resizes the terminal below 120x24 while the TUI is already running, a small
WindowSizeMsgflows into the model and the same layout breakage becomes reachable. This is a degenerate case (and it affects the whole layout, not just the detail panel), so it was intentionally split out of #40 rather than fixed there.Options to consider
visibleRows()never goes below a sane floor and the placeholder/body lines are always width-fit (truncate/pad), so a too-small frame degrades gracefully instead of corrupting.Follow-up from the TUI work under #32 (#40), but deferred out of the v0.2.0 scope: the startup gate keeps this unreachable on launch, so it does not block #32. Scheduled for the v0.5.0 production-readiness / hardening pass.