Thanks @jensenpat — this is an unusually well-root-caused PR, and the write-up made it straightforward to verify. I checked each fix against the existing code and the claims hold up:

• The stopDax() ownership guard mirrors the existing pattern in onDaxChannelChanged() (MainWindow.cpp ~18394) exactly, including the #ifdef HAVE_RADE handling (m_radeDaxStreamId is declared under that guard in MainWindow.h). Channels 1–4 is consistent with every registration site (registerDaxStream callers all gate on 1–4), so nothing can be leaked by switching from daxStreamIds() to the per-channel loop.
• Erase-vs-zero in the stream-removed handler is safe for in-flight creates as described: pending entries hold value 0 and the handler early-returns on streamId == 0, so they can never match. The erase(it); break; pattern is fine.
• The grace-timer lifecycle looks right: stop() stops the timer before its existing immediate releaseDaxForTci(), the timeout lambda re-checks for live audio clients before releasing, and clearing m_tciDaxSlices on radio disconnect closes the deferred-release-after-radio-bounce hole. scheduleDaxRelease() falling back to immediate release when the timer is null is good defensive coding.

One real gap worth addressing (or explicitly deferring to #3305): borrowed-stream ownership after the bridge stops.

When TCI has borrowed a bridge-created stream (m_tciDaxBorrowedChannels contains the channel) and the user toggles the DAX bridge off, the new stopDax() guard correctly keeps the stream alive for TCI — that's the #3363 fix. But the channel stays marked borrowed in TciServer, so when TCI later releases (client quits, grace expires), releaseDaxForTci() skips it (TciServer.cpp:1946) — it neither sends stream remove nor unregisters it from PanadapterStream. The owner that would have cleaned it up (the bridge) is already gone, so the stream is orphaned on the radio until disconnect. Pre-PR this couldn't happen because stopDax() removed everything (the bug); post-PR an orphan is strictly better than silenced RX, but it's a new leak.

Suggested fix: when stopDax() keeps a stream solely because TCI owns the channel, transfer ownership — e.g. a small TciServer::adoptDaxChannel(int ch) that removes the channel from m_tciDaxBorrowedChannels, so the eventual releaseDaxForTci() removes the stream like one it created. If you'd rather not grow the API in a hotfix, a comment noting the orphan case + a pointer to #3305 would be acceptable.

Minor (non-blocking):

• The main-thread watchdog will log a huge spurious "stalled ~N ms" warning after system suspend/resume or laptop lid-close (the gap is wall-clock). Log-only so it's harmless, but consider capping/annotating gaps above a few seconds so field logs don't get misread as multi-hour stalls.
• The qCWarning elevation means every normal client quit (graceful audio_stop + disconnect) now logs warnings in routine operation. The rationale (teardowns should never be silent) is sound for the diagnostic phase — just flagging that once the remaining Tune/ATU stall is fixed, the audio_stop/disconnect lines are candidates to drop back to qCInfo, keeping releaseDaxForTci() itself at warning.

No scope concerns — all four files are within the stated fix/diagnostic scope, no AppSettings/QSettings or RAII issues, and error handling at the boundaries (null m_daxReleaseTimer, QPointer model, disconnected-radio guard in releaseDaxForTci) is in place. Nice work, and thanks for the live-rig validation detail.

_{🤖 aethersdr-agent · cost: $6.0343 · model: claude-fable-5}

Claimed; read full diff, all five commit messages, PR body, bot review, and field validation notes.

The three DAX-RX lifecycle fixes are sound — the ownership guard, the erase-not-zero key fix, and the debounce timer all compose correctly and the hardware-validated evidence (stream 0x04000009 removal timestamp, WSJT-X console throw, monotonic frames_sent across profile switches) meets Principle VIII. Not blocking on the logic.

Blocking: two mechanical adaptations required for the #3351 MainWindow decomposition.

PR #3545 ("RadioSession owns TciServer + CatPorts") merged 2026-06-13 04:29, after this PR was opened. Both items are one-line fixes; the underlying intent is unchanged.

1 — Wrong target file.
The MainWindow.cpp hunk targets stopDax() at the old monolith line ~18312. That method now lives in MainWindow_DigitalModes.cpp:1070. The ownership-guard block belongs in MainWindow_DigitalModes.cpp — not back in MainWindow.cpp.

2 — Stale member reference.
The patch adds:

const bool tciUsing = m_tciServer && m_tciServer->ownsDaxChannel(ch);

m_tciServer no longer exists as a MainWindow member. The replacement accessor is defined in MainWindow.h:503–504:

TciServer* tciServer() const { return m_session->tciServer(); }

The correct line — identical to the pattern already used in onDaxChannelChanged() at MainWindow_DigitalModes.cpp:1169, which this PR references as the model — is:

const bool tciUsing = tciServer() && tciServer()->ownsDaxChannel(ch);

m_radeDaxStreamId and daxStreamIdForChannel() are both already in scope in MainWindow_DigitalModes.cpp; no other adaptation needed in that TU. TciServer.cpp, TciServer.h, and main.cpp are unaffected by the refactor and are correct as written.

@ten9876 flagged the member rename above and offered to take the rebase — worth taking him up on that given the MainWindow.cpp → MainWindow_DigitalModes.cpp redirect is a second wrinkle on top of it.

Requesting changes only on the rebase adaptation; happy to flip to approved once the two items above are resolved.

Thorough, well-reasoned hotfix bundle — the writeup, the field correlation, and the in-code comments make each change easy to verify. I traced all three fixes against the surrounding code and they hold up. CI is green across all six checks (build, macOS, Windows, CodeQL, accessibility).

What I verified:

• Fix #1 (stopDax ownership guard) — correctly mirrors the existing guard in onDaxChannelChanged() (MainWindow_DigitalModes.cpp:1162-1188): same daxStreamIdForChannel(ch) / ownsDaxChannel(ch) / m_radeDaxStreamId triad, same HAVE_RADE gating. Kept streams stay registered (no unregisterDaxStream), which is the right behavior. Switching from iterating daxStreamIds() to channels 1–4 is fine since DAX RX is 1–4.
• Fix #2 (erase-not-zero) — the reactive handler now erase(it); break; immediately, so the erase-during-iteration is safe, and dropping the key lets ensureDaxForTci()'s contains(ch) guard (TciServer.cpp:1904) fall through to recreate. The streamId != 0 match correctly protects in-flight (value 0) creates. m_tciDaxBorrowedChannels.remove() alongside is correct.
• Fix #3 (debounced teardown) — m_daxReleaseTimer is parented to this (cleaned up with the object), single-shot, re-checks anyAudio when it fires, stop() tears down immediately, and cancelDaxRelease() on audio_start cancels it. Clearing m_tciDaxSlices on radio disconnect to prevent a late setDaxChannel(0) on recreated slices is a nice catch.

Two minor, non-blocking notes:

1. Routine events now log at qCWarning — audio_stop and a clean client disconnect (e.g. a normal WSJT-X quit) now emit qCWarning, not just genuine fault paths. I understand why (the qCInfo teardown logs were invisible in the 26.6.2 bundles), but a clean shutdown isn't a warning, and users skimming logs at default levels may read these as errors. Consider gating the warning on "there was actually DAX to tear down" (e.g. only warn in scheduleDaxRelease/releaseDaxForTci when !m_tciDaxStreamIds.isEmpty()), keeping the routine ack at info. Not a blocker given the diagnostic intent.

2. Watchdog message slightly overstates the stall — in main.cpp, gapMs is the full inter-tick gap, which includes one nominal ~250 ms heartbeat interval, so the actual block is closer to gapMs − 250. The "stall began ~gapMs before this line" line will read ~250 ms early. Cosmetic for a diagnostic, but worth a tweak if you want the timestamp math to land precisely.

Neither affects correctness. Nice work root-causing this with hardware in the loop and keeping the fixes contained while the structural refcounting waits on #3305. Thanks @jensenpat!

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

Both items from our CHANGES_REQUESTED on the prior head are resolved. Reviewing the full updated diff at 5de583c2.

Our two required items:

New content added in this revision:

• erase() vs it.value() = 0 (m_tciDaxStreamIds): The old zero-value left the map key present, which prevented a new stream from being created on that channel after a profile switch (#3476). erase() removes the entry entirely so the profile-switch path can insert fresh. ✅
• m_tciDaxSlices.clear() on disconnect: Prevents stale setDaxChannel(0) from firing on newly-recreated slices after reconnect. ✅
• m_tciDaxBorrowedChannels.remove() on stream removal: symmetric teardown. ✅
• replyText(): Centralized per-command echo + qCDebug trace replacing scattered ws->sendTextMessage() calls throughout onTextMessage(). Clean. ✅
• scheduleDaxRelease() / cancelDaxRelease() with kDaxReleaseGraceMs = 10000: 10 s debounce before releasing DAX back from TCI; transient WSJT-X reconnects survive. Logs at qCWarning for visibility. ✅
• Stall watchdog (src/main.cpp +27): 250 ms heartbeat QTimer logs when the GUI event loop stalls > 600 ms. Uses qWarning() without a named category — intentionally unconditional for always-visible diagnostics; slightly off the qCWarning(lc*) convention used elsewhere but the intent is clear and the deviation is justified.

6/6 CI green. Approved.