Nice fix — the root-cause analysis is spot on (a hard-pinned minimumSize from minimumSizeHint() with no screen clamp), and the remedy is minimal and local. The mechanics check out:

• Conventions ✓ — AppSettings (not QSettings), QSignalBlocker RAII guard, and screen() is null-checked via the availableScreenHeight() helper returning 0 when undeterminable.
• Recursion is bounded — the auto-engage path sets m_compactButton->setChecked(true) then re-enters updateCompactMode(), which now takes the if (compact) branch, so it can only recurse one level. Good.
• Backstop coverage is coherent — the required.setHeight(availH) fallback only reaches the no-compact-button case, since when a compact button exists and is unchecked the auto-engage branch handles it first.

All six checks (build, macOS, Windows, CodeQL) pass.

A couple of small, non-blocking notes:

1. Auto-engage vs. the persisted setting. The auto-engage uses QSignalBlocker, so it correctly does not persist FlexControlCompactMode — good, it stays re-evaluated each launch. But the consequence is: on a short screen, if a user manually unchecks Compact, the toggled handler (FlexControlDialog.cpp:1045) writes "False" + saves, then calls updateCompactMode(), which immediately re-engages compact under the blocker. The button visibly bounces back to checked while settings now read "False". It's harmless (re-derived on next launch), but the bounce is slightly confusing UX — worth a comment noting the toggle is intentionally pinned on a screen too short for the full layout.

2. Test is environment-dependent. flex_control_dialog_size_test reads the real primary screen. On a CI runner with a tall virtual display (or the offscreen platform reporting a large default), availH >= kFullLayoutFloor, so the two meaningful assertions (compact auto-engaged) are skipped and only the minH <= availH invariant runs — which a tall non-compact window also satisfies. So the regression-specific path isn't guaranteed to be exercised in CI. The headline minH <= availH invariant is still a real guard, so this is fine as-is, just flagging that the "did compact actually auto-engage" coverage is opportunistic rather than deterministic.

Neither is a blocker. Thanks for the thorough writeup, the proof table, and flagging the automation-bridge gap (openMenu/menu-launched-dialog) separately — that's genuinely useful context. 👍

_{🤖 aethersdr-agent · cost: $2.3932 · model: claude-opus-4-8}

Thanks for the thorough writeup and the standalone regression test, @jensenpat — the root-cause analysis (hard-pinned ~1114 px minimum with no screen clamp) is clear and the fix is appropriately minimal and local.

What looks good:

• Reuses the existing, already-fitting compact layout rather than inventing a new path — clean.
• Proper guards throughout: m_compactButton null-check before setChecked, screen() null-check in availableScreenHeight(), and QSignalBlocker to avoid re-entrant toggle signals.
• The updateCompactMode() recursion is bounded — the re-entry sets the button checked first, so it takes the compact branch and returns; no infinite loop.
• Correctly does not persist the auto-engaged state to FlexControlCompactMode — it's an adaptive runtime decision, so the user's stored full-mode preference is preserved if they later move to a taller display. Nice.
• Uses AppSettings (not QSettings) in both the fix and the test, per convention.
• All 6 CI checks pass; the new GUI test follows the same build-only (no add_test()) pattern as the neighboring help_dialog_test, which is consistent for display-dependent tests.

One minor note — the compact-path backstop comment in applyCompactWindowSize():

// ... the body may need to scroll, but the window stays fully on-screen and
// resizable rather than clipping off the bottom edge.

Two small inaccuracies for the extreme case (a screen shorter than the compact layout's own ~887 px minimum):

1. There's no QScrollArea wrapping the body, so the body can't actually scroll — the clamp squeezes/clips the widgets rather than offering a scrollbar.
2. The very next line calls setFixedHeight(required.height()), which pins the height, so the window isn't resizable taller either.

The fix is still strictly better than the old behavior (the window stays on-screen instead of overflowing), and this path is a rare edge (sub-~887 px usable height), so it's not a blocker — just worth tightening the comment so it doesn't overstate "scroll" / "resizable" for that corner. No change needed to the logic itself.

Solid fix overall.

_{🤖 aethersdr-agent · cost: $1.3754 · model: claude-opus-4-8}

Verified the fix on every path:

• Recursion terminates: updateCompactMode() branches on m_compactButton->isChecked() at the top, so the non-compact branch setting setChecked(true) then recursing lands in the compact branch. The QSignalBlocker correctly suppresses the redundant signal-driven re-entry.
• Backstop on both paths (non-compact and applyCompactWindowSize) clamps required.height to availH, so even when compact is unavailable or the screen is shorter than the compact layout, the window stays on-screen and resizable rather than clipping.
• availableScreenHeight() is null-safe (screen() returns primary even pre-show; 0 skips the clamp), uses availableGeometry() (taskbar-excluded), and is cross-platform (QScreen) — good given the cross-platform principle even though the bug was Windows-reported.
• The auto-engaged compact is screen-driven, not persisted — correct, so a later move to a tall screen restores the full layout.

The regression test (flex_control_dialog_size_test) asserts the enforced minimum never exceeds the available screen height + compact auto-engages on a short screen — solid guard, builds green.

And the menu-launched-dialog bridge gap recorded here was just closed by #3819 (closed-menu invoke + menu open), so this dialog is now bridge-openable for future automated checks. Thanks @jensenpat.