Reviewed the full diff against the checked-out branch, with focus on the refcounting core, thread-safety, and the teardown/recreate paths. This is a strong, well-reasoned change — the "no commands from status-echo edges" invariant is the right structural fix for the #4009 storm class, and centralizing ownership into PanadapterStream collapses the old O(consumers²) cross-peeking into one clean refcount. All six CI checks are green (build, check-windows, check-macos, CodeQL, analyze cpp, a11y). Thanks for the thoroughness, @jensenpat — the get dax / tci bridge verbs making the assertions reproducible is a nice touch.

What I verified holds up

• No emit-under-lock. acquireDaxChannel captures needCreate/streamId inside the locked block and emits daxStreamCreateNeeded only after the QMutexLocker scope closes; scheduleDaxRemovalLocked/scheduleDaxRecreateLocked only arm a timer while locked. Good.
• No double daxStreamUnregistered. In the grace-removal lambda the entry is erased before calling unregisterDaxStream(removeId), so the inner scan finds nothing (channel stays 0, no emit) and the lambda emits once explicitly; the subsequent radio "removed" echo then no-ops (id already gone from m_daxStreamIds). Single emit per teardown — confirmed for both the radio-initiated and grace-window paths.
• generation invalidation correctly expires in-flight deferred lambdas across re-acquire / disconnect-reset, and createPending guards against duplicate stream create.
• registerDaxStream unlocking before emit daxStreamRegistered is correct (it's a QMutexLocker, .unlock() is valid).
• Cross-thread signal flow is sound: PanadapterStream lives on m_networkThread, and the create/remove signals queue to the RadioModel main-thread lambdas.

Minor, non-blocking

1. Doc/default port mismatch. docs/automation-bridge.md shows "port":40001 in the tci start example, but the code defaults to AppSettings.value("TciPort", "50001"). Worth aligning the example (or noting it's illustrative) so a reader doesn't assume 40001 is the default.

2. TCI sim leaves m_tciSim armed on a server-initiated close. The disconnected handler only sets m_tciSimCloseReason; it doesn't null/deleteLater m_tciSim. So after the server drops the socket, tci start returns "already running" until an explicit tci stop. Fine for a test harness, but a one-line auto-clear (or a doc note) would make the reconnect-shape tests less surprising to drive.

3. Observation, not a regression: if a stream create is emitted but the radio never answers (no stream status ever arrives), the channel stays createPending=true / streamId=0 and held, with no retry — the scheduleDaxRecreateLocked path only re-arms on radio-initiated teardown of an existing stream. This matches the old behavior (which also depended on the radio honoring the create), so it's not something this PR needs to solve — just flagging the one gap the recovery logic intentionally doesn't cover.

Nothing here blocks merge. Nice work.

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

Review: request changes

Deep pass on the DAX-ownership refactor (multi-agent finders + adversarial verify). The direction is right — one refcounted acquire/release table replacing three mutually-peeking trackers, and the "no commands from status-echo edges" invariant genuinely kills the #4009 storm by construction. But the new command plane is fire-and-forget with no failure handling, which reintroduces the exact wedge class (#3669) the PR claims to eliminate, plus a confirmed RADE channel-tracking bug. Each inline comment carries a fix (apply-able suggestion where clean, a code sketch where it spans files).

Blocking:

1. stream create failure permanently wedges the channel (RadioModel.cpp:407) — fire-and-forget + !isConnected() drop, and createPending is never cleared on failure, so the channel is silently dead with no recovery until a full disconnect. This is the #3669 wedge, reintroduced for the first-create path.

Should fix in this pass (small, localized):
2. RADE's hold doesn't follow a mid-session dax= change (MainWindow_DigitalModes.cpp:1062) → RADE silent + old-channel stream leaks; the reconciler is Bridge-only.
3. Create→remove churn when the last holder releases while a create is in flight (PanadapterStream.cpp:1550) — contradicts the anti-storm goal.
5. TCI simulator is left a zombie after a server-side close (AutomationServer.cpp:4250), blocking tci start — and this is the harness the PR ships to prove the behavior.

Notes:
4. TCI orphans its stream on slice removal (Bridge-only sliceRemoved release) — pre-existing, but this PR is the place to close it.
6. generation bump missing in the recreate path. 7. daxStreamRegistered is a dead signal with a misleading comment.

Threading is clean, for the record — m_streamMutex guards all shared state, emits are outside the lock, snapshot is locked. And one finder claim was refuted: the reconnect "phantom-teardown" can't happen (radio reaps all streams on disconnect + the client_handle filter blocks stale status).

The core refcount design is sound; these are gaps in the failure/edge handling around it. Independent of the other open PRs, so nothing else is blocked.

Human-directed independent review (Claude / @NF0T)

Full diff verified against jensenpat/fix/3305-dax-stream-refcount (d9ff740). Independent pass on all six items from @ten9876's review, plus the bot findings.

Confirmed blocking

Issue 1 — stream create fire-and-forget wedges channel permanently (RadioModel.cpp:407-408)

Independently confirmed. sendCommand() has no response callback. The !isConnected() early-return silently drops the signal with no feedback to PanadapterStream; acquireDaxChannel has already latched createPending=true, and the re-acquire guard (streamId==0 && !createPending) blocks all retries. The only clearer is registerDaxStream() on success — never called on a radio error reply. A slots-exhausted or connect-gap drop leaves the channel terminally wedged until full disconnect. This is the #3669 wedge reintroduced on the first-create path.

Confirmed should-fix

Issue 2 — RADE reconciler gated on m_daxBridge (MainWindow_DigitalModes.cpp)

Confirmed. The reconciler early-returns on !m_daxBridge, leaving RADE's DaxConsumer::Rade hold unreconciled when the slice's dax= channel changes mid-session: old channel stream leaks, new channel never created, RADE goes silent without any bridge activity.

Issue 3 — Create→remove churn when last holder releases during in-flight create (PanadapterStream.cpp:~1550)

Confirmed. releaseDaxChannel bumps generation (correctly expiring the grace timer), but the stream create is already on the wire. registerDaxStream re-inserts with holders==0 and schedules another removal — a full create+remove cycle for a channel nobody wants.

Issue 5 — TCI sim zombie after server-side close (AutomationServer.cpp:4253)

Confirmed. The disconnected handler only records the close reason; m_tciSim is never nulled. tci status reports running=true, and tci start rejects with "already running." This stalls the automated re-arm sequences that the PR uses as live proof — blocking the harness that proves the fix.

Confirmed notes

Issue 6 — Missing generation bump in scheduleDaxRecreateLocked

Confirmed (line ~1650: createPending=true without ++m_daxGenCounter). Every other createPending=true mutation pairs with a gen bump; this path inconsistently doesn't, making the timer-invalidation reasoning for the recreate path unsound relative to the immediately preceding reset.

Issue 7 — daxStreamRegistered dead signal

Confirmed. Zero connections in the PR branch; only daxStreamUnregistered is wired. The header comment promising "TCI invalidates its channel→trx cache on daxStreamRegistered" is unimplemented.

Issue 4 — TCI sliceRemoved orphan (pre-existing, natural place to close)

Confirmed pre-existing. TciServer has no sliceRemoved connection; slice removal doesn't zero daxChannel, so the Tci holder bit is never released on slice teardown.

Refutation corroboration

@ten9876's refuted phantom-teardown finding: independently confirmed his refutation is correct. The client_handle filter in registerDaxStream blocks foreign stream status adoption, and the radio reaps all streams on disconnect. Phantom-teardown cannot occur.

What's sound

Threading is clean: m_streamMutex guards all shared state, emits happen after lock release, the needCreate flag pattern (capture inside lock, signal outside) is correct throughout. Echo-triggered command path confirmed eliminated — onDaxChannelChanged records state only, no commands. Idempotency guards in acquire and release confirmed. Generation/lambda expiration correct except the single missing bump noted above. The refcount core design is solid; the issues are in the failure and edge paths around it.

Human-directed independent review (Claude / @NF0T)

Thanks for this, @jensenpat — this is a genuinely well-executed refactor. Collapsing three mutually-peeking ownership trackers into one refcounted authority in PanadapterStream is the right shape, and the "never emit commands from status-echo edges" invariant is stated clearly and actually held throughout the diff. The header docs and the get dax / tci automation verbs make the whole thing testable without log-grepping, which is a real win.

I verified the two earlier reviewer concerns against the current head (4d9c3cb) — both are already fixed in this revision:

1. Fire-and-forget stream create wedge (@ten9876's headline). Resolved. RadioModel::RadioModel now sends the create via sendCmd(...) with a response callback that calls m_panStream->notifyDaxCreateFailed(ch) on a non-zero code, and also calls it immediately on the !isConnected() drop path. notifyDaxCreateFailed clears createPending and, if the channel is still held, arms a kDaxCreateRetryMs retry — so an error reply or a connect-gap drop no longer leaves holders>0 / streamId==0 / createPending=true terminal. The suggested fix landed essentially verbatim.

2. RADE hold not following a mid-session dax= change (@ten9876 item 2). Resolved. activateRADE now wires m_radeDaxReconcileConn on the RADE slice's daxChannelChanged, acquiring the new channel before releasing the old, independent of m_daxBridge. deactivateRADE disconnects it and releases m_radeDaxChannel. The old-channel leak / new-channel-never-created path is closed.

Both were valid on the commit they were filed against; they're now false positives against current head.

Other things I checked and they're clean:

• No dangling references to the deleted symbols (ownsDaxChannel, m_tciDaxStreamIds, m_radeDaxStreamId, scheduleDaxRxStreamRemoval, etc.) — only a stale-comment mention survives in TciServer.h:58, harmless.
• The removal-timer path releases m_streamMutex before re-entering unregisterDaxStream() (non-recursive mutex — no deadlock), and daxStreamUnregistered fires exactly once since the entry is erased first.
• sliceRemoved orphan-release wired for both Bridge and Tci holders; generation-counter cancellation of in-flight deferred lambdas is consistent across acquire/release/reset.
• Conventions honored: AppSettings (not QSettings) for TciPort, enum class : quint8, RAII connections, structured bindings. No new flat keys, TX path untouched.

Two minor, non-blocking notes:

• Disconnected-retry spin. If a consumer holds a channel while isConnected() is false, the daxStreamCreateNeeded → notifyDaxCreateFailed → retry cycle self-loops every kDaxCreateRetryMs until connect or resetDaxChannelsForDisconnect() bumps the generation. It's low-frequency (2 s) and self-healing, so fine as-is — just flagging that onConnected reconciliation (which @ten9876 also suggested) would let it re-fire promptly rather than waiting up to one retry interval. Optional given the disconnect reset already clears the table.

• Merge conflicts. GitHub reports mergeable_state: dirty and a merge-tree against main shows conflicts — this needs a rebase before it can land. Not a code issue, just housekeeping.

Nice work — the design and the test surface are both solid. 👍

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

Review (2nd pass): approve

Re-reviewed against the rebased head. Every blocking item from the first round is resolved, and a fresh adversarial sweep of the fix commits surfaced two new issues that are now fixed. Rebased onto current main and pushed the fixes directly (the branch was CONFLICTING).

First-round issues — all resolved (verified against code, not just commit messages)

Refcount core re-swept clean: no emit-under-lock, single daxStreamUnregistered per teardown, no recursive-mutex re-entry, channel bounds enforced, generation cancellation consistent.

Two new findings from this pass — fixed and pushed

A. tci stop abrupt null-derefs m_tciSim (a regression introduced by the item-5 fix). abort() emits QWebSocket::disconnected synchronously, re-entering the teardown lambda while m_tciSim was still set; the stop path's following deleteLater() then fired on a dangling pointer — reachable via the tci stop abrupt verb this PR ships. Fix 5285f549: null m_tciSim (and snapshot the audio flag) before abort()/close() so the lambda's guard no-ops; graceful audio_stop preserved.

B. #1439 nudge over-fires on WAN/SmartLink. The nudge-skip gate read a channel-scoped latch set by whichever registration status preceded the create reply — not correlated to the create's generation, reset only on disconnect. When the auto-bind slice= status arrives after the reply (reachable on the WAN transport, outside the >=4.2.18 LAN capture), the gate defaulted false and fired a same-value slice set dax= re-assert — the transient dax=0/dax=<ch> + audio blip it exists to prevent. Fix dbe5238f: decide the nudge in handleDaxRxStreamRegistry, where the binding is definitively known and the path is already filtered to our streams. Race-free across transports, zero behavior change on the captured LAN path; the racy latch is deleted.

Both build clean (AetherSDR, no new warnings).

Left as non-blocking follow-ups

• Disconnected-retry self-loop (0.5 Hz) if a channel is acquired inside the disconnected window — bounded and self-heals on reconnect.
• notifyDaxCreateFailed reply callback isn't generation-guarded — not exploitable today (pending callbacks aren't flushed on disconnect); cheap future hardening.

Excellent refactor — collapsing three mutually-peeking ownership trackers into one refcounted authority with the "no commands from status-echo edges" invariant is the right structural fix for the #4009 storm class. Approving.