[jensenpat]

Implements the approved RFC #4764, Frameless window retrofit: one 52 px unified title bar with radio tabs, rebuilt on Qt 6.12's window-hint APIs. Supersedes #4906 and #5489.

What the bar is

One 52 px bar owns the application menu, the brand mark, the radio tabs, the audio cluster, the applet dock/float controls and the window controls.

• Application menu
  • On Windows and Linux (no native menu bar), the menus live behind a ☰ button that leads the bar, ahead of the brand.
  • The QMenuBar stays as a hidden child. MainWindow still builds into it, and the automation bridge still resolves actions through it.
  • The button opens the menu with popup() (no nested event loop).
  • The menu and its submenus have rounded corners (8 px, like the radio tabs) and slightly see-through panels (color.titlebar.menu.background, 0.92 alpha).
  • Item text starts at the same x in every menu, whether or not the menu has checkable items.
  • Leaf shortcuts and each menu's Alt+letter mnemonic keep working.
  • macOS keeps its system menu bar.
• Radio tabs
  • One tab per known radio: LAN, SmartLink or routed. Hide/restore is persisted.
  • The strip takes the bar's free width and scrolls only once that runs out. A vertical wheel scrolls it, and dragging a tab sideways pans it; a drag is not a click.
  • Line one is the name. Line two is the state in words (WCAG 1.4.1); the model shows only when a nickname hides it.
• Link indicator, folded into the radio's own tab dot
  • The standalone heartbeat lamp is gone. The dot pulses per heartbeat.
  • On an unexpected loss it goes red (blinking, or solid with blink off) and line two and the accessible name read "link lost".
  • The alarm stays on the radio that dropped. Its tab is kept visible even when the radio was removed from the strip, reached by address, or has aged out of discovery.
  • A deliberate disconnect, a new session, or removing that tab clears it. A user disconnect never raises it.
• "+" discovery popover
  • Search, per-radio Actions (Disconnect / Rename… / Radio setup… / Remove from or Add to tabs), Connect manually… and Rescan radios.
  • It does not rebuild under an open Actions menu.
• Rename dialog
  • A non-modal PersistentDialog (themed, remembered geometry, follows frameless mode).
  • The demo's "not on the air" label cannot be renamed.

Window chrome per platform (src/gui/WindowChrome.h)

Platform	Mode	Window controls
macOS (cocoa)	ExpandedClientAreaHint + NoTitleBarBackgroundHint, empty unified NSToolbar for 52 px light placement	Native traffic lights: tiling menu, Stage Manager and native fullscreen
Windows	ExpandedClientAreaHint + NoTitleBarBackgroundHint (Qt owns the frame, shadow, rounded corners and resize borders; replaces our nativeEvent/DWM frame)	Shared painted caption chips. Qt's own title and caption buttons are suppressed: they render unreliably and in the OS light/dark colour. WS_MINIMIZEBOX/WS_MAXIMIZEBOX are restored on the HWND
Linux (xcb/Wayland)	FramelessWindowHint + FramelessResizer (6 px band, no top-edge resize under the bar, #4886)	Shared painted caption chips. Title drag uses startSystemMove(), except on xcb, where the #4827 manual move is kept

View → Frameless Window remains the escape hatch everywhere. docs/architecture/window-chrome.md documents the design.

The main window is opaque (WA_TranslucentBackground off). The bar paints a pre-composited opaque fill and a 1 px hairline (WA_OpaquePaintEvent). Its containers are made transparent by object name, so MainWindow's window-wide QWidget rule cannot slab them.

Also in this change

• Bridge
  • get titlebar and the titlebar verb (selectRadio / showDiscovery / minimize / maximize / close) expose geometry, tabs, link state, chrome mode and the ☰ menu.
  • The new applet verb (dock left|right, float on|off, show, hide, state) covers the dock/float controls.
  • Actions validate synchronously and run on the next main-loop turn ("deferred":true, with the pre-action snapshot).
  • selectRadio refuses a hidden tab.
  • applet state is allowed in observe-only mode.
• Applet dock/float
  • One coherent dock/float/visible state.
  • PanadapterStack::refreshAfterLayoutShift() re-realizes native pan windows after a dock flip on macOS (Metal) only. Elsewhere it is a repaint sweep.
• Tokens: 22 new tokens, 20 color.titlebar.* and 2 color.brand.*, documented in docs/theming/canonical-tokens.md. The theme seed is regenerated.
• Tests
  • unified_title_bar_test (new, socket-free) covers:
    • fill and cascade, tab insets, the status line
    • wheel overflow, the link alarm and its carrier across a drop
    • the minimal-mode separator, the keyboard-only focus ring
    • popover search/actions and its deferred rebuild
    • the ☰ menu, Alt mnemonics, shortcuts and minimal mode
  • minimal_mode_exit_order_test now anchors on the exit branch's restoreGeometry().
  • automation_boundary_core_test pins the deferral and observe-only contract.

Maintainer rulings (@ten9876)

• Accepted:
  • the Qt 6.12 native-caption approach in place of the RFC's custom-drawn bar on all three platforms
  • the opaque window, which retires the backdrop-alpha experiment
  • the applet verb
  • 22 tokens (the RFC estimated 15)
  • the ☰ application menu
• Revised acceptance: the RFC decision-2 platform checks land open and are tracked in Unified title bar (#6198): native-platform checks still open — Windows Snap Layouts, #4557 drift, macOS M1, xcb move #6224. That issue covers:
  • Windows /winbuild
  • the W1 Snap Layouts hover regression
  • fix(windows): preserve frameless window top-edge position #4557/Reopen #3478 for framless window #4328 top-edge drift
  • W2/W3
  • macOS M1 real-pointer input
  • the xcb/GNOME move
  • fractional-scale Wayland feel

Screenshots (macOS 27.0.1, Qt 6.12.0, isolated profile, built-in demo radio, nothing on the air)

🤖 Generated with Claude Code

[aethersdr-agent]

Hi @jensenpat — CI on 1f2f7147 went red, and it's a one-line fix in a generated file. Nothing wrong with the title bar work.

What failed

Static checks, at the step aetherd touchpoint manifest (job):

::error::aetherd-touchpoints.md is stale — run `python tools/gen_touchpoint_manifest.py`

That step is python tools/gen_touchpoint_manifest.py --check (static-checks.yml:197). Everything else in that job passed, including the colour ratchet and the accessibility analysis.

Why

I fetched the branch and reproduced it. The regenerated manifest differs from the committed one by exactly one row:

-| `core/ThemeManager.h` | 162 | ui-support — Qt token-based theming singleton …
+| `core/ThemeManager.h` | 165 | ui-support — Qt token-based theming singleton …

The column is "how many files include this touchpoint header", and this branch adds three new GUI files that include core/ThemeManager.h:

• src/gui/BrandMark.cpp
• src/gui/RadioTabBar.cpp
• src/gui/WindowCaptionButtons.cpp

162 + 3 = 165. Confirmed with git diff origin/main...1f2f7147 -- src/ | grep '#include.*ThemeManager': three additions, no removals. The branch never touches docs/architecture/aetherd-touchpoints.md, so it's simply never been regenerated since those files landed.

The header total stays at 239 — the five new src/gui/ headers aren't touchpoints themselves, they're consumers, so no new rows. This is just the one count.

The fix

python tools/gen_touchpoint_manifest.py
git add docs/architecture/aetherd-touchpoints.md

One line changes. Worth re-running after any rebase too — #6195 and #6140 also regenerate this manifest (different rows, so they should merge clean, but the regen is free insurance).

Scope of this report

• Not CI infrastructure — this is a genuine stale generated file, and the checker is right.
• The other three jobs (build, check-macos, check-windows) were still in progress when I looked, so I can't speak to them. Sanitizer option configures passed. If check-macos does go red, the most likely cause is the one you already flagged under Test gates: mixer_control_availability_test linking TitleBar.cpp and needing src/gui/mac/NativeWindowTitle.mm in the if(APPLE) block of tests/tests.cmake. I haven't seen that fail — just noting where I'd look first.
• No Copilot or reviewer comments on the PR yet, so nothing there relates to this failure.

Thanks for the careful writeup on this one — the honest Test-gates checklist and the explicit RFC deviation table make this much easier to review. 73

---

_{🤖 aethersdr-agent · cost: $5.3245 · model: claude-opus-5}

[aethersdr-agent]

1. Issue fit

Implements the approved RFC #4764 and delivers most of it: the single 52 px bar, the brand mark, radio tabs with a worded status line, the + popover, the heartbeat folded into the active tab's dot (with the solid-red-when-blink-off rule preserved — I checked RadioTabBar.cpp:616-640), the de-emojified audio cluster, the tokens, and the get titlebar / titlebar bridge surface. The right-click blink toggle the RFC's risk 4 promised did move onto the tabs (TitleBar.cpp:259), and the View-menu checkbox still routes through the same setBlinkEnabled().

Partially, on one named RFC deliverable: feature 7 and the use case "Snap Layouts on Windows 11 — hover the maximize button, get the layout flyout" were part of what @ten9876 approved, and this branch regresses them (W1) rather than shipping them, because it hands caption drawing to Qt. The RFC's own problem statement (§2) is Snap Layouts' absence. The deviation is honestly disclosed and the macOS half of the trade is clearly better than approved (decision 3's lost tiling menu comes back) — but "approved RFC feature not delivered on the platform the RFC named it for" is a maintainer call, not a reviewer one. Same for the ~31 px Qt caption buttons vs the RFC's 46 px (W2).

The PR is self-declared Draft with four Windows gates, one Linux gate and one macOS gate unchecked. Nothing below is a reason to re-open that; it is already open.

2. Scope

RFC implementation scope was "14 files, ~1100 insertions". This is 35 files, 4734 insertions.

File / group	What it changes	Claimed?	Verdict
TitleBar.*, BrandMark.*, RadioTabBar.*, WindowCaptionButtons.*, WindowChrome.h, mac/NativeWindowTitle.*	The bar itself	Yes (RFC + body)	In scope
MainWindow.{h,cpp}, MainWindow_Session.cpp, MainWindow_Menus.cpp	Bar wiring, tab feed, chrome config	Yes	In scope
resources/themes/*, ThemeSeedGenerated.cpp, canonical-tokens.md, logo-96.png, resources.qrc	21 tokens + asset (RFC said 15)	Yes	In scope; token growth undisclosed, see nits
AutomationServer.{h,cpp} — titlebar verb + get titlebar	RFC feature 9	Yes	In scope (new public surface — see B1)
AutomationServer.{h,cpp} — applet verb	New public bridge verb: dock/float/show/hide/state	No — body never mentions it; only commit ee5ac3b does	Needs maintainer decision, + body update
AppletPanel.cpp, PanadapterStack.{h,cpp}	Docked-panel background + refreshAfterLayoutShift() for the dock flip	No	Explained by 58b4e30/ee5ac3b, not by the body — name it in the body
ConnectionPanel.{h,cpp} (+ MainWindow_Session.cpp dialog)	selectRadio/selectManualConnection/rename plumbing; QInputDialog → PersistentDialog	Partly (the popover needs the selectors)	In scope-adjacent; the nickname-dialog rewrite is a side effect, disclose it
docs/qt612-window-chrome.md (new, 186 lines)	Branch diary	No	Blocker B2
docs/automation-bridge.md, docs/architecture/aetherd-touchpoints.md	Verb/model docs, manifest count 162→165	Yes	In scope
tests/tests.cmake, tests/unified_title_bar_test.cpp, tests/titlebar_headphone_mute_test.cpp	New test + link sets	Yes	In scope

No CHANGELOG.md entry — correct.

Socket-test record: this PR adds no socket-owning test and removes none. tests/unified_title_bar_test.cpp is socket-free (no QTcpServer/QLocalServer/QUdpSocket/listen/connectToHost); it is registered in tests.cmake:7186 and joins AETHER_SETTINGS_CONSUMERS. It is not in any ctest -R filter in ci.yml, so the body's 18/18 is a local result and CI does not gate it.

3. Blockers

B1 — src/core/AutomationServer.cpp:9244-9263: doTitleBar runs a button click and a window close synchronously inside the socket read callback, against this file's own written rule

Credit: security-audit (CodeGuard), confirmed against the code.

    if (!m_titleBarActionHandler(action.trimmed(), target.trimmed(), &why)) {

That handler is MainWindow::automationTitleBarAction, and its three sinks are exactly the ones this file defers everywhere else:

• selectRadio → tab->click() (MainWindow.cpp:4562) — a QAbstractButton click. AutomationServer.cpp:4499-4503 on the invoke click path: "a click can open a popup menu or modal dialog with a nested event loop; run synchronously inside the QLocalSocket read callback it corrupts socket/window state (SIGSEGV in QWindow::geometry()). Defer to a clean main-loop turn… (#3646)". Clicking a tab reaches showConnectionDialog(), which raises a top-level window.
• showDiscovery → RadioTabBar::showDiscoveryPopover() — constructs a popover with a QMenu per row and shows it. doShowMenu defers for this reason.
• close → close() (MainWindow.cpp:4588) or emit caption->closeRequested(), direct-connected to window()->close() (TitleBar.cpp:601). doClose at 9722 wraps the identical call in QTimer::singleShot(0, qApp, …) and replies "deferred": true, with the rationale in its header: "a confirm-dialog closeEvent can't re-enter the socket callback".

The aggravating detail: the new function was inserted immediately beneath doWindow's #3918 header block, which is still at 9238-9243 and still says

// State changes don't spin a nested event loop, so they're safe to run
// synchronously here (unlike click/menu, which defer).

so doWindow's documentation is now orphaned above a body that does both the click and the close that sentence excludes, and reads as this function's own justification.

Second half, same hunk at 9264-9266: after the handler has run close(), doTitleBar calls m_titleBarSnapshotHandler() to build the echo — reading a MainWindow that has already run its whole closeEvent teardown (MainWindow.cpp:3921+: settings save, socket disconnects, thread wait()). Not a use-after-free today — MainWindow sets no WA_DeleteOnClose — but it is one the day that changes.

Fix: defer, as the siblings do, and take the snapshot before the action rather than after.

    QJsonObject reply{{QStringLiteral("ok"), true},
                      {QStringLiteral("action"), action.trimmed()}};
    if (!target.trimmed().isEmpty()) {
        reply.insert(QStringLiteral("target"), target.trimmed());
    }
    // Snapshot BEFORE the action: `close` tears the window down, and the
    // post-action read would inspect a MainWindow that has already run
    // closeEvent. Re-read `get titlebar` to confirm the result.
    if (m_titleBarSnapshotHandler) {
        reply.insert(QStringLiteral("titlebar"), m_titleBarSnapshotHandler());
    }
    reply.insert(QStringLiteral("deferred"), true);
    return reply;

…with the handler call itself moved into deferInvokeAction(...) / QTimer::singleShot(0, qApp, …). The validation half has to stay synchronous so an unknown action or a missing tab still errors — splitting "resolve and validate now, activate on the next turn" is the shape invoke click already uses.

doAppletPanel at 9289 has the same structure: applyAppletPanelState() creates and tears down the top-level applet float window (MainWindow.cpp:4501-4520) from the read callback. Lower confidence that it can spin a loop, but it's the same invariant, so I'd apply the same treatment.

The docs change needs a matching correction: docs/automation-bridge.md currently promises "The reply echoes the post-action get titlebar snapshot, so a caller never needs a follow-up read."

B2 — docs/qt612-window-chrome.md: a personal branch diary, and it is false against current main

The first paragraph:

This is a development migration, not a release-toolchain change. CMake requires Qt 6.12; the local macOS SDK is the official 6.12.0 preview package dated 2026-09-01. Windows/Linux CI and release packaging remain on their upstream toolchains and cannot build this branch unchanged. Do not publish it as a release-ready, cross-platform-verified migration.

That was true when it was written and is not true now. main already carries the Qt 6.12 floor — CMakeLists.txt:315, find_package(Qt6 6.12 REQUIRED …), shipped with v26.10.1 (8df6db2f, "Qt 6.12") — and this PR's CMakeLists.txt diff does not touch it. At head 93d39e02, build (Linux), check-windows, check-macos, Static checks and Sanitizer option configures are all green. A merged doc telling the next reader that CI cannot build this tree is worse than no doc.

The rest of the file is branch-local process notes, not architecture: a fork branch (jensenpat/AetherSDR/tree/aether/applet-picker), a local laptop bundle name (AetherSDR qt612-applet-picker-0de5a2b6-dirty 1748.app), SFTP/quarantine/ad-hoc-signing steps, "preserved locally on aether/applet-picker-integration", a worktree-local build/qt-sdk recipe, and two dated "Local evidence" sections including "Computer Use clicked the + button". That belongs in the PR body (where most of it already is), not in docs/.

What's genuinely worth keeping is the ~40 lines that describe the shipped design: the WindowChrome.h policy table, the per-platform notes, and the radio-switcher behaviour table. Those read as architecture and would sit well as docs/architecture/window-chrome.md. My ask is: keep that, drop the diary and the stale toolchain framing.

4. Nits (non-blocking)

• src/gui/AppletPanel.cpp:284-296 — the new comment's premise is contradicted by this same PR: "MainWindow is WA_TranslucentBackground, so its paintEvent is the only thing filling any region the widget tree leaves bare". WindowChrome::configure() sets window->setAttribute(Qt::WA_TranslucentBackground, false) and the body says the window is now opaque. The second half of the comment (Qt excludes native QRhi children from the backdrop) is the part that still holds; the first clause will send the next reader looking for an attribute that isn't set.
• tests/tests.cmake:6444 — connection_panel_size_test gained src/gui/PersistentDialog.cpp, but 115e822e moved the dialog out of ConnectionPanel. grep PersistentDialog src/gui/ConnectionPanel.cpp now matches only a comment (ConnectionPanel.cpp:1610). Looks like a leftover from the pre-115e822e shape.
• docs/automation-bridge.md get titlebar — RadioTabBar::state() also returns linkPulse, linkAlarm, linkOverrideColor and discovered[].canRename, none of which the doc mentions. linkPulse/linkAlarm are the fields that make the body's "the heartbeat is asserted rather than eyeballed" claim true (and the RFC's use case names linkPulse explicitly), so they're the ones most worth documenting.
• resources/themes/*.json, canonical-tokens.md — the body admits color.titlebar.background.mac is now unused. Dropping it in this PR is cheaper than a follow-up that has to touch both themes, the seed and the token count again. Also worth a body line that the RFC's "15 new tokens" became 21.
• src/gui/TitleBar.cpp barState() — WindowChrome::usesNativeCaption(window()) and window()->windowFlags() are unguarded two lines above window() && window()->windowFlags()…. QWidget::window() won't return null here, so this is consistency rather than a crash, but the mixed guarding suggests one of the two readings is wrong.
• src/gui/MainWindow_Session.cpp (radioTabActivated lambda) — m_connPanel->selectRadio(radioId) returns bool and the result is dropped. ConnectionPanel::selectRadio only searches m_radios/m_wanRadios, so clicking a tab for a SmartLink radio while logged out, or for the routed/"Manual" synthetic tab, opens the picker on whatever page it was on with no feedback.
• src/gui/MainWindow_Session.cpp (radioActionRequested remove/restore) — settings.setValue("RadioSwitcher", …) result is unchecked; docs/agents/settings.md asks writers to check. The JSON document also carries no schema version, where Principle V asks for "one versioned JSON document" (the "one object per feature, not another loose flat key" half is satisfied, and app-global is the right scope for a hidden-tab list).
• src/gui/MainWindow_Session.cpp statusFor for SmartLink — wan.status.compare("Available", Qt::CaseInsensitive) != 0 means an empty or unrecognised status renders as "in use", i.e. "another station has it". Defaulting the unknown case to Available would be the safer read.
• src/gui/RadioTabBar.cpp showDiscoveryPopover() — "Discovered radios" and "Connect manually…" are bare QStringLiteral while everything around them is tr().
• src/gui/PanadapterStack.cpp — refreshAfterLayoutShift()'s native re-realize is macOS-only by design, so if the dock-flip see-through strip reproduces on Windows/Linux the repaint sweep alone won't fix it there. Reasonable given no repro, but it's worth saying out loud that 58b4e30 is a macOS fix.

5. What I tried to break (and didn't)

• Bridge auth and authorization ordering on the new verbs. The constant-time token gate (AutomationServer.cpp:3935) and the observe-only gate (3963) both run in handleLine before verb dispatch, and titlebar/applet are absent from isReadOnlyRequest's safe set (2723-2786), so they fail closed in observe-only mode. get titlebar rides the get entry and is a pure read. No bypass.
• TX-guard bypass. Neither verb reaches a keying path, and titlebar close is not a new app-terminating capability — the pre-existing close <target> verb already closes top-levels. No Principle VI issue introduced.
• Injection / unknown-token fall-through. Both handlers are exact-match allow-lists with return fail(...) tails (MainWindow.cpp:4501-4522, 4552-4598); target is used only as an equality key against tab->entry().id and echoed JSON-encoded. doTitleBar not lower-casing action while doAppletPanel does is an inconsistency that fails closed.
• Handler lifetime. All four are null-checked (9250, 9278, 9285) and their [this] captures are MainWindow, which owns m_automation as a unique_ptr member — so it outlives the server. Only the post-close() snapshot (B1) is exposed.
• Deleted guards. Every - line citing an issue (#4827, #4886, #4328, #2584) is code motion, not removal: those comments and their guards still exist in head at FramelessResizer.h, WindowGeometryRestore.h, MainWindow.cpp:2593 and MainWindow_Workspace.cpp:412. The other - lines with hex in them are hardcoded colours going away, which matches the body's −50 colour-reference claim.
• The light-theme caption-glyph contrast I suspected. color.titlebar.caption.glyph resolves to {color.gray.100} = #506070 on a #f5f5f8 bar — that's the same ink as text.secondary, so it passes. Not a finding.
• Applet state machine. The two "deliberately not representable" combinations are actually enforced in code, not just in the doc: applyAppletPanelState forces visible = true when floating (MainWindow.cpp:9719-9721), and hide passes floating=false (4520). The QSplitter-won't-re-slot-a-hidden-child comment at 9742-9750 describes a real Qt behaviour and the show-then-move order handles it.
• Rename-path equivalence. The removed QInputDialog branch and the new PersistentDialog route end at the same hl2::Hl2Discovery::setNickname + relabel + eager commit; showRadioContextMenu's early return after renameRadio() is correct because setRadioNickname() does the relabel and emits radioNicknameChanged(). The one behaviour change is the match key (serial only, vs family && serial in the surviving clear-nickname path) — harmless unless two families share a serial.
• addDemoRadio — demo.serial is assigned before radioDisplayName(demo, …), so the simulator's nickname override resolves rather than silently falling back.
• Test-link completeness. Only four tests.cmake targets compile src/gui/TitleBar.cpp and all four gained the three new sources; the if(APPLE) foreach covers the same four. No target is left short of NativeWindowTitle.mm.

Everything above is reasoned from reading the code at /tmp/aetherclaude/pr-6198 — I ran no build, no test and no GUI. The whole class of findings the open gates cover is outside what I can reach: macOS native hit-testing under the empty NSToolbar (M1), Snap Layouts hover (W1), Qt's caption-strip synthesized press (W3), Windows top-edge drift (#4557), and Wayland fractional-scale drag/resize. I also cannot judge the screenshots' "before" against anything I can render.

6. Recommendation

Needs maintainer decision, with B1 and B2 to fix first.

B1 is a concrete correctness fix inside the PR's own new code and should land before the Windows/Linux gates get spent on a build that can crash the bridge on titlebar selectRadio. B2 is a one-file decision. Beyond those, the three things only @ten9876 can rule on are: the undelivered Snap Layouts feature from the approved RFC, the opaque-window default that retires main's backdrop-alpha experiment, and the applet verb as new permanent public bridge surface arriving unannounced.

The bar itself is good work, and the test is the honest kind — it mirrors MainWindow's real stylesheet cascade so the bug it was written for (TitleBar {} never matching a namespaced class) actually reproduces in it, and it checks a rendered pixel rather than asserting the implementation back at itself. Thank you for the RFC correction note and for listing the gates as unchecked rather than claiming them.

---

_{🤖 aethersdr-agent · cost: $18.7288 · model: claude-opus-5}

[ten9876]

The implementation substantially covers approved RFC #4764 (brand, two-line radio tabs, discovery panel, audio controls and bridge inspection), but partially satisfies it: the approved Windows Snap Layouts feature is explicitly absent, and the RFC's required Windows/Linux platform checks are still unchecked. Reviewed head cbc4872897efab44c7748214c65864991c5cc85f against merge base 12df694349c0f57081c24563783e267447fc3b20.

Scope

File/group	Change	Claimed?	Verdict
TitleBar.*, BrandMark.*, RadioTabBar.*, WindowCaptionButtons.*, WindowChrome.h, mac/NativeWindowTitle.*	Unified bar, tabs, controls, platform chrome	Yes	RFC implementation; platform acceptance remains outstanding
MainWindow.*, MainWindow_Session.cpp, ConnectionPanel.*	Discovery/session integration, hide/restore, rename dialog, opaque main window	Yes	Disclosed; opaque-window default needs Jeremy's ruling
MainWindow.cpp status-bar styling hunks	Change station border, separators, inactive indicators, automation chip, FFT icon and CPU/TX colours below the main content	No specific claim or RFC requirement	Unbundle unrelated visual changes (B1)
AppletPanel.cpp, PanadapterStack.*, MainWindow_Menus.cpp, applet-state portions of MainWindow.*	Dock/float state correction and Metal refresh	Yes	Disclosed adjacent bug fixes; no new Windows/Linux native re-realization
AutomationServer.*, docs/automation-bridge.md	titlebar and applet public verbs, deferred actions	Yes	titlebar approved in RFC; applet needs Jeremy's decision
resources/themes/*, ThemeSeedGenerated.cpp, canonical-token docs	20 tokens and generated seed	Yes	In scope
Logo, resource registration, CMake, tests/tests.cmake, titlebar tests	Assets, build integration and coverage	Yes	In scope
Architecture index/window-chrome docs and touchpoint manifest	Documentation and generated include count	Yes	In scope; ThemeManager count rises 162→165 through the three declared new widgets

No commit predates the branch's initial August 6 feature commit. The body usefully discloses dock/float work and three maintainer decisions, but its list does not explain the separate status-bar visual changes.

Blockers

1. Unbundle the status-bar restyle. src/gui/MainWindow.cpp:5593 changes the bottom status bar's border and separator/inactive colours; :5628 changes the automation chip (including adding a border); :5656 changes the status FFT glyph; :5929 changes CPU warning colours, and :6133 changes the inactive TX label. The station border also changes at :364. None implements the 52 px title bar, and none is identified as a separate defect or accepted requirement in #4764. Using tokens is a valid cleanup, but it also changes existing rendered values outside the approved surface. CONTRIBUTING.md says “One issue per PR. Keep changes focused and reviewable.” GOVERNANCE.md lists “Any change to visual design — colors, fonts, spacing, theme, icons” under RFC-required changes. Keep the title-bar token work here; move these unrelated status-bar hunks into their own proposal/PR. This is a scope finding from the diff, not a reproduced rendering defect.

2. Complete the expressly required platform acceptance, or obtain an explicit revised maintainer ruling. src/gui/WindowChrome.h:25 replaces the prior Windows custom-frame path with expanded-client-area hints, while src/gui/TitleBar.cpp:684 hides the shared caption controls when native captions are used. The PR body acknowledges that this implementation does not deliver the RFC's Windows 11 maximize-hover Snap Layouts and leaves /winbuild, #4557 top-edge drift, Windows pointer delivery and fractional-scaling Wayland checks unchecked. The maintainer's RFC #4764 decision 2 expressly says “it becomes a PR gate rather than an RFC gate”, with /winbuild, deliberate #4557 regression coverage and fractional-scaling Wayland checks named. Headless QWidget tests cannot settle those native interaction questions. Supply that evidence and deliver the accepted Snap Layouts behaviour, or have Jeremy explicitly revise the acceptance criteria; do not present the RFC as fully implemented before then. This is missing required acceptance evidence and an acknowledged feature gap, not a locally reproduced Windows defect.

Nits and maintainer decisions (non-blocking on their own)

• Rename dialog misses runtime chrome propagation, reasoned from code: src/gui/MainWindow_Session.cpp:537 constructs a PersistentDialog but does not register it in m_persistentDialogs. ConnectionPanel::setFramelessMode() updates only itself; MainWindow's propagation loop updates tracked dialogs. Add trackPersistentDialog(dialog); before showing it, so an already-open rename dialog follows View → Frameless Window. I could not drive this path because the full app build hit environment quota.
• src/gui/TitleBar.cpp:110 still claims the design system forbids emoji outright, although the RFC explicitly withdrew that unsupported appeal. State only the rendering/theme reason, and shorten the long historical comments in RadioTabBar.cpp:750 and PanadapterStack.cpp:355 per AGENTS.md's comment guidance.
• Jeremy / @ten9876: decide the disclosed opaque-window default at src/gui/WindowChrome.h:37, the new permanent applet verb at src/core/AutomationServer.cpp:3697, and the changed native-caption approach. The RFC approved a design; these disclosed deviations do not receive approval merely because the code compiles.

Verification and attacks

• Test-boundary preflight passed: added/modified test sources introduce no socket-owning peer. Built only unified_title_bar_test with pinned Qt 6.12, Release, in /tmp/pr6198-review; it passes offscreen.
• Mutation-checked active-tab truth: removing applyActiveState() before radioActivated produces FAIL: re-clicking the active tab leaves it checked and FAIL: clicking an inactive tab does not check it. Restored the exact source and rebuilt/re-ran the passing head target. This validates genuine behavioural coverage of both active and inactive re-clicks.
• Read the hidden/compact tab carrier, overflow wheel mapping, blink-disabled solid alarm, deferred QPointer tab activation, malformed bridge actions and applet side/idempotence paths. The focused test also exercises theme fill/cascade, tab insets, search/actions, overflow and alarm clear. No additional defect was established by these attacks.
• Ran the four seam gates on exact merge base and head: 102 engine findings unchanged in signature, zero blocking growth; capability booleans 70→70; raw above-seam commands 369→369; manifests current. Head theme seed and bridge-doc generation checks pass. No checker/baseline weakening in the diff. Automated code-review skill unavailable.
• No app/bridge session: the full build stopped before compilation with AutoGen ... Writing depfile ... failed / ninja: ... Disk quota exceeded. A focused test build succeeded after freeing only this review's artifacts. No existing instance was driven, no hardware was connected, and no runtime persistence/native-pointer/dock-rendering claim is independently verified here. macOS claims remain author evidence; Windows/Linux native gates remain open.
• CI is stale relative to current main: earliest run creation on this head was 2026-10-05T06:43:19Z, current main tip 334276112 is dated 2026-10-05T07:51:14Z. With strict: false, green checks do not prove the current merge result.

Recommendation: Request changes. Unbundle the unrelated status-bar styling and complete/revise the explicit native-platform gates. The focused titlebar test and mutation check are useful positive evidence, but they cannot replace native interaction checks or Jeremy's outstanding design/public-surface decisions.

[ten9876]

Reviewed at head cbc48728. I built it on Linux against Qt 6.12.0 and drove it visibly on a Hyprland Wayland desktop at 1.667× fractional scale, connected only to the built-in demo radio (DEMO-0001, isolated settings, TX disabled). That is the Linux gate the body leaves open. The prior agent review was against 93d39e02; I re-checked its two blockers on this head (both fixed, see below) rather than relying on it.

1. Issue fit

This implements approved RFC #4764, and the Qt 6.12 deviation is disclosed honestly. The bar, the tabs with a worded status line, the popover, the get titlebar / titlebar surface and the heartbeat folded into the tab dot are all present and working on Linux. The remaining RFC-level calls are the ones the body already names as maintainer decisions: W1 Snap Layouts, the opaque window, and the applet verb. One correction to the body: it says "Draft.", but isDraft is false, so the PR is open for merge as it stands.

2. Scope

File / group	Claimed?	Verdict
TitleBar.*, RadioTabBar.*, BrandMark.*, WindowCaptionButtons.*, WindowChrome.h, mac/NativeWindowTitle.*	Yes	In scope
MainWindow*.cpp/.h: chrome wiring, tab feed, rename dialog, Windows nativeEvent/#4328 re-anchor removal	Yes ("our nativeEvent/DWM code (removed)")	In scope
MainWindow.cpp:1144: FramelessResizer::install(this, 8), which drops topMoveReserve and widens 6 → 8 px on every edge	Only the top band is mentioned	Undisclosed for the bottom and side edges. See nit 1
TitleBar.cpp: removal of the xcb manual-move fallback (#4827)	No	Blocker 2
AutomationServer.*: titlebar verb, get titlebar	Yes (RFC feature 9)	In scope
AutomationServer.*: applet verb	Yes ("please rule")	Needs maintainer decision. New public bridge surface
AppletPanel.cpp, PanadapterStack.* (dock-flip strip)	Yes	In scope. The re-realize is macOS-only, as the body says
ConnectionPanel.*: rename moved to PersistentDialog, selectors	Yes	In scope. Side effect noted in nit 6
Themes, seed, canonical-tokens.md (20 tokens vs the RFC's 15), logo, qrc	Yes	In scope
docs/architecture/window-chrome.md, automation-bridge.md, README index, touchpoint manifest (ThemeManager includers 162 → 165)	Yes	In scope
tests/tests.cmake, unified_title_bar_test.cpp, titlebar_headphone_mute_test.cpp	Yes	In scope. Socket-free (step-0 preflight: no socket or peer in any added test source)

There is no CHANGELOG.md entry, which is correct. Engine boundary: check_engine_boundary.py reports 102 findings on both the merge base and the head, and the per-file diff shows only line shifts. gen_touchpoint_manifest.py --check is clean on both.

The prior review's blockers, re-verified on this head:

• B1 (fixed): doTitleBar/doAppletPanel now validate synchronously and run the action through deferInvokeAction (AutomationServer.cpp:9245-9314), taking the snapshot first. Driven live: the replies carry "deferred":true with the pre-action state; applet state read 1 s later shows the flip (side:right → left, splitterIndex 3 → 2); unknown actions and missing tab ids fail synchronously ("no radio tab with id 'nope'").
• B2 (fixed): docs/qt612-window-chrome.md is gone and its design content is in docs/architecture/window-chrome.md.

3. Blockers

1. src/gui/RadioTabBar.cpp:664-678: after an unexpected link loss, the red "link lost" alarm is painted on whichever radio's tab happens to come first, not on the radio that dropped

    if (m_activeId.isEmpty()) {
        for (RadioTab* tab : m_tabs) {
            if (tab->entry().visibleInTabs) {
                return tab;
            }
        }
    }

When the session drops, refreshRadioTabs() clears the active id (MainWindow_Session.cpp:210, activeSerial is empty when disconnected). The carrier then falls back to the first visible tab, and onHeartbeatLost() raises the alarm on that tab 4.5 s later. LAN radios are listed first, so on any network with a second radio, the radio you were never connected to is the one that goes red.

Reproduced on the demo, with a FLEX-8600 also on the LAN. Bridge, sim disconnect, then get titlebar once per second:

  0.2s alarm False active '' [('2125-1213', 'available', 'Radio FLEX-8600, available')]
  3.4s alarm False active '' [('2125-1213', 'available', 'Radio FLEX-8600, available')]
  4.4s alarm True  active '' [('2125-1213', 'available', 'Radio FLEX-8600, available')]
  5.5s alarm True  active 'DEMO-0001' [('DEMO-0001', 'connected', ...)]

A grab RadioTabBar at +4.7 s shows the red alarm ring on "FLEX-8600 · available · KK7GWY", while the Simulator tab, which actually dropped, shows a plain grey dot. The body's own pitch for this design is "One dot answers both 'which radio' and 'is its link alive'", and here it answers "which radio" wrongly. An operator with two radios is told that the idle one lost its link.

Fix: keep the carrier on the radio whose link this is until a different session starts. For example:

void RadioTabBar::setActiveRadio(const QString& id)
{
    if (m_activeId == id) {
        return;
    }
    if (!id.isEmpty()) {
        m_carrierId = id;   // the link the heartbeat describes, kept through a drop
    }
    m_activeId = id;
    applyActiveState();
}

RadioTab* RadioTabBar::linkCarrierTab() const
{
    const QString& id = m_activeId.isEmpty() ? m_carrierId : m_activeId;
    for (RadioTab* tab : m_tabs) {
        if (tab->entry().id == id) {
            return tab;
        }
    }
    return nullptr;
}

This needs a QString m_carrierId; next to m_activeId in RadioTabBar.h:199. Whether a user disconnect should also clear it is your call; clearLinkAlarm() already handles that path. Please also add a unified_title_bar_test case with two tabs, the second one active, then setActiveRadio({}) plus the alarm, asserting that the second tab is the carrier. The current suite passes with this bug present.

2. src/gui/TitleBar.cpp:810-824: the #4827 xcb manual-move fallback was removed, so dragging the title bar is dead again under QT_QPA_PLATFORM=xcb on Mutter/XWayland

startWindowMove() is now only windowHandle()->startSystemMove(). On main (12df69434:src/gui/TitleBar.cpp:580-640), xcb skipped the system move and used a grabbed manual w->move(), because, per FramelessMoveHelper.h:11-14, which is still in the tree:

On xcb, startSystemMove()/startSystemResize() report success but the WM grab is silently dropped under Mutter/XWayland (QTBUG-69716, #4827)

On xcb startSystemMove() returns true, so the new code accepts the press and nothing moves the window. That is the exact symptom #4827 closed ("Click-and-hold on the menu bar to move the window: the cursor changes to the drag hand, but the window never follows the pointer"). git log -S systemMoveResizeUnreliable traces the removal to 0e0cf124, and the body doesn't mention it. FramelessResizer kept its own xcb fallback, so resize still works; only moving the window regressed. xcb is still reachable as the wayland;xcb fallback (main.cpp:299), on plain X11 sessions, and for anyone who sets QT_QPA_PLATFORM=xcb, which #4725 calls the common setup.

Fix: restore main's branch, so that if (FramelessMoveHelper::systemMoveResizeUnreliable(w)) takes the manual move with grabMouse(), continueWindowMove, and finish on release. It only applies on the Linux frameless path now, because macOS and Windows use native captions.

Reasoned from code, not reproduced. I can't generate a real compositor pointer drag here, and Hyprland is not Mutter. The bridge's synthetic pointer verbs don't go through a WM grab either, so they can't prove or disprove this. A one-minute check on GNOME with QT_QPA_PLATFORM=xcb settles it.

4. Nits (non-blocking)

1. MainWindow.cpp:1144: the 6 → 8 px band widens the existing #4886 exposure. Measured live in a 1400×800 window: the status-bar controls (automationChip, addPanadapterButton, "Cancel transmit", …) span y = 757–798, so 6 px of each now sits inside the bottom resize band, up from about 4 px. Clicks there resize the window instead of activating the control. The pan-menu column at x = 2 loses the same 2 px on the left edge. #6018, which insets the status bar for the 6 px band, is still open and will need to account for 8. Please state the margin change in the body.
2. Stale comments left by the topMoveReserve / #4328 removal: TitleBar.h:34-38 (still "MainWindow can pass it as FramelessResizer's topMoveReserve … must stay in lockstep"), FramelessResizer.h:20-21 and :58-61 ("MainWindow reserves TitleBar::kHeight"), MainWindow.h:877-883 (a #4328 comment orphaned above toggleMinimalModeFromAction() after its declaration was deleted), MainWindow.cpp:9648 ("under WA_TranslucentBackground, shows the desktop"; the window is opaque now), and PanadapterStack.h:79-80 ("elsewhere this is just the repaint sweep", although refreshAfterReparent()'s non-mac branch calls resetGpuResources() on every pan per flip).
3. src/gui/WindowGeometryRestore.{h,cpp} is now dead. Nothing in src/ calls clampFrameToWorkArea or parseSavedWindowGeometry, yet the file is still in CMakeLists.txt:1173, still included by MainWindow.cpp:15, and still pinned by window_geometry_restore_test. Delete it with its test, or say it's being kept for the #4557 gate.
4. MainWindow_Session.cpp:502-505: SmartLink tabs outlive a logout. m_smartLinkRadios is a copy that nothing clears. ConnectionPanel clears its own list (ConnectionPanel.cpp:1280, :2210), but the strip keeps showing those radios as "available", which contradicts the comment at :225 ("the strip and the picker can never disagree"). The tab-click fallback text handles the click, but not the false status.
5. The link alarm is colour-only to a screen reader. While linkAlarm was true (the 5.5–6.6 s rows above), the carrier tab's accessible name read "Radio Simulator (not on the air), connected". The PR advertises the status line as WCAG 1.4.1 words, but the one state the dot exists to show has no words. Given #4896, I'd add "link lost" to the status text and accessible name while m_alarm is set.
6. The demo's "not on the air" label is now user-overridable. addDemoRadio() now runs the label through radioDisplayName(), and get titlebar reports "canRename": true for DEMO-0001. main hardcoded the nickname because "the nickname carries the unmistakable 'not on the air' label". The model ("AetherSDR Demo") still appears on line two once renamed, so this is low-risk, but it is a deliberate safety label becoming editable. Either exclude the sim family in canRenameRadio() or say it's intended.
7. applet state is refused in observe-only mode. isReadOnlyRequest() (AutomationServer.cpp:2720) has no entry for it, although the doc and the handler both call it read-only.
8. Nothing pins the deferral contract. No test covers titlebar/applet returning deferred plus the pre-action snapshot. A socket-free AutomationServer handler test would keep B1 from silently regressing.

5. CI and evidence

• All five checks are green, but the runs were created 06:43Z and main moved at 07:51Z (#6173, #6176: sanitizer lane and WDSP; no file overlap with this PR). The green describes a merge base that is no longer main's tip.
• Built and ran locally (Linux, Qt 6.12.0, offscreen): unified_title_bar_test, titlebar_headphone_mute_test, hl2_pc_audio_lock_test, mixer_control_availability_test, frameless_resizer_test and window_geometry_restore_test all pass. connection_panel_size_test fails one check ("horizontal overflow is reachable"), and it fails identically on the merge base, so that is my environment and not this PR.
• Mutation: removing m_dockSep->setVisible(!on) (TitleBar.cpp:1545) makes unified_title_bar_test fail with minimal mode leaves no dangling separator (got 1, want 0). Restoring the line (sha256 matches git show HEAD:) makes it pass again.

6. What I tried to break that held

• No false alarm after a user disconnect (body claim): disconnect, then 8 s of get titlebar showed linkAlarm false throughout. It holds.
• Unexpected loss raises and clears the alarm: it raised at 4.4 s and cleared about 2 s after the auto-reconnect. The timing matches the body; only the tab is wrong (blocker 1).
• Tabs clear the 8 px top band: live screenRect y = 8, h = 36 in a 52 px bar. No interactive bar child starts in the top 8 px except drag-handle labels and the caption container, whose 36 px chips sit at 8–44.
• Dock flip on Linux: applet dock left/right on the demo. A grab MainWindow after each flip shows no unpainted strip.
• refreshAfterReparent "back to macOS-only, as on main": the function body is byte-identical to the merge base.
• The showDiscovery popover opens on the deferred turn (popoverVisible true one second later).
• Opaque window: no orphaned backdrop-alpha setting or menu remains. Only the stale comment in nit 2.

Linux gate status (RFC decision 2): the bar, caption chips, tab insets, dock flip, popover and link indicator all render and work on Wayland at 1.667×. Not proven: drag jitter and real-pointer resize feel, because I have no way to inject a real pointer here, so that part of the gate stays with a human. One environment note so nobody chases it: on Hyprland the floating window's Qt state reported maximized while the compositor kept it at 1400×800, which suppresses FramelessResizer edges. That is a compositor interaction I did not compare against main, and I'm not counting it against this PR.

7. Recommendation

Request changes for blockers 1 and 2. Both have small, local fixes. The maintainer decisions the body lists (the applet verb, the opaque window, W1 Snap Layouts, 20 tokens vs 15) are still open and independent of these. The Windows and macOS M1 gates are untouched by this review.