1. Issue fit

Yes, on the core defect. #5164's mechanism — unknownModel() at connect → connectionStateChanged evaluates takesTxAudioOverSeam && canTransmit once → late capabilitiesChanged never re-runs the TX-audio lifecycle → feedDaxTxAudioInternal drops every TCI block — is closed by rebinding to RadioModel::capabilitiesChanged (MainWindow_Session.cpp:753), which RadioModel::publishCapabilities (src/models/RadioModel.cpp:4112) emits on the connect edge, the disconnect edge, and every backend capability revision. The idempotent helper is exactly the "Suggested implementation direction" the issue asked for, and removing modelForName() from the connect path is the issue's "do not infer hardware identity from the nickname" taken literally.

Acceptance criteria mapping: custom name can't alter TX capability ✅ (onSessionConnected now unconditionally &unknownModel()); late false→true re-evaluates without restart ✅; regression covering custom name → unknown → CI-V reply → TCI PCM → submitTxAudio() ✅ (tests/icom_identity_test.cpp:116-142 drives the real AudioEngine::feedDaxTxAudio and asserts zero frames before identity, one after — it would fail against unfixed code); RX-only fail-closed ✅ (icom_identity_test.cpp:202-206); no duplicate capture for Flex/Sim/HL2 ✅ (:193-201, plus the !isTxStreaming() / !isRxStreaming() guards). Live dummy-load proof is claimed nowhere in the body — that criterion is unmet and worth stating.

One confirmed collateral breakage (Blocker 1): tests/icom_backend_test.cpp is a registered CTest target that this PR does not touch and that asserts the now-removed behavior.

2. Scope

No CHANGELOG.md entry — correct. No settings-schema, credential, dialog or a11y surface touched.

Socket-test surface (disclosure, not a finding): this PR adds no socket-owning test and no fake peer. icom_identity_test constructs a real IcomSession but never calls start(); frames enter through onCivFrame directly (tests/icom_identity_test.cpp:22-41). It links aethercore and joins AETHER_SETTINGS_CONSUMERS. It is not on the frozen PR gate — it first runs on full-suite.yml after merge, per AGENTS.md.

3. Blockers

1. icom_backend_test asserts behavior this PR deletes, and it is not on the PR gate — so green CI does not cover it

src/core/backends/icom/IcomCivBackend.cpp:1366 now calls publishIdentity() unconditionally at onSessionConnected, before emit connected() at :1396. publishIdentity() always sets r.model (:~5900), and m_model is kUnknown whose name is "Unknown Icom" (IcomModels.cpp:161).

tests/icom_backend_test.cpp:2376 snapshots publishedModel inside the connected() handler and asserts:

check(modelAtConnect.isEmpty(),
      "without misreporting the custom nickname as an early hardware model");

That is now "Unknown Icom", not empty. icom_backend_test is registered at tests/tests.cmake:602-605 and is deliberately absent from the per-PR -R allow-list (.github/workflows/ci.yml:487 even carries a comment about it having fallen off a gate before), so all five green checks on cc3b8aa prove nothing about it — it runs on full-suite.yml after merge.

I read this rather than ran it, but the chain is mechanical: unconditional publishIdentity() before connected(), r.model always assigned, kUnknown.name non-empty.

The surrounding block (:2328-2385) and the "CI-V ADDRESS RESOLUTION" section that follows (:2400+, CivCase, retarget and two-responder cases against FakeIc705) were written for the old state machine. Please rerun that target locally and update it in this PR — either assert "Unknown Icom" as the honest pre-identity placeholder, or, if this is the moment to retire that fake-peer fixture under the #5254 remediation, delete the affected cases and say so in the body. Landing with it stale means the first full-suite run after merge fails on main.

2. A pinned CI-V address that doesn't match the radio now fails silently in the one place the old code was loudest

IcomCivBackend.cpp:1673-1678 drops any 19 00 reply whose source differs from a pinned address before adoptCivIdentity can compare them. The deleted code (old adoptReportedCivAddress) emitted a named warning for exactly this case:

"This radio reports CI-V address %1, not the %2 that was entered. The entered address is being used."

with a comment stating why it was load-bearing: "on a point-to-point radio it means the typed address is simply wrong and the symptom (a connected radio that answers nothing) names no cause at all."

Post-merge, a pinned-address typo produces five dropped replies and then only the generic exhaustion text ("Check its network CI-V settings and selected CI-V address"), which never mentions that the radio did answer and did name a different address. The reply is in hand; naming it costs one branch. This is the removed-guard-whose-symptom-recurs case from §3 — I'd rather see it restored than argued away, but it's a narrower loss than the old code's, so if you disagree, say so in the body and I'll defer.

4. Nits (non-blocking)

• tests/tests.cmake:574-577 — icom_identity_test constructs a live AudioEngine, which reads AppSettings (AudioEngine.cpp:1855, :4121, :5117). It is correctly added to AETHER_SETTINGS_CONSUMERS (:4341) but does not use tests/TestSettingsProfile.h, so it reads and can write the developer's real store. anan_settings_test.cpp:35 and antenna_alias_test.cpp:29 show the one-line pattern. I could not find a canon sentence mandating it, so: convention, hence a nit.
• profileMap()'s modelId is genuine new bridge surface. It's documented and read-only, but it belongs in the PR body's change list, not only in docs/automation-bridge.md.
• AudioEngine.cpp:1 puts core/backends/RadioCapabilities.h above AudioEngine.h, so the own-header-first convention no longer proves AudioEngine.h is self-sufficient. Cosmetic.
• The body claims nothing about live proof. #5164's last acceptance bullet asks for dummy-load evidence (fresh TX bytes, nonzero forward power, safe unkey). Worth stating plainly that it wasn't run, rather than leaving it unmentioned.

5. What I tried to break (and failed)

• "capabilitiesChanged doesn't cover disconnect, so capture leaks." It does: RadioModel.cpp:1991 wires connectionStateChanged → publishCapabilities(connected), and applyBackendAudioCapabilities's (wasSeamAudio || seamAudio) && isTxStreaming() branch is strictly wider than the old seamTxAudio && isTxStreaming() — it closes capture even when the backend has already reset canTransmit, which the old code did not. Genuine improvement, not a regression.
• "audioStartTx/audioStartRx did more than the raw engine calls." They don't — MainWindow.cpp:4657-4677 are bare QMetaObject::invokeMethod wrappers onto m_audio. Substituting startTxStream/startRxStream inside a lambda already queued to m_audio is equivalent, and pcAudioEnabled/pcAudioRequired reduce algebraically to the same predicate set (hostModulates is the only discriminator, and it's still checked before RX starts).
• "A silent radio now reconnect-loops for five seconds." It doesn't. The CI-V stall watchdog in onLinkTick runs above the new m_civReported == 0 gate, but it is driven by profileFor(*m_model).civRecovery, and only the IC-9700 declares one (IcomModels.cpp:653); kUnknown has none. Discovery therefore can't trip the reconnect path.
• "The rejected-identity early return starves the scheduler." onMeterTick still calls pumpCiv(now) before its own gate (IcomCivBackend.cpp:5980), so dispatch keeps draining while unidentified — including the emergency unkey queued by the ambiguity branch. Reads expire on kReadTimeoutMs = 350 anyway, well inside the 1 s retry.
• "Ambiguity now fires on the radio's own duplicate reply." adoptCivIdentity:1273 treats same-address/same-ID as inert before the conflict branch, so a retry landing after a late first reply is absorbed. icom_identity_test:139-140 pins it.
• "Withdrawing the model traps a keyed radio." No: setKeying is now gated on key && !hasTransmit (:4591), so unkey always reaches the radio, and the conflict branch calls setKeying(false) before reassigning m_model and without reverting the session address — Principle VI holds through the withdrawal. icom_identity_test:169-178 pins both halves.
• Sibling call sites: modelForCivAddress has zero remaining references tree-wide; modelForName has zero production callers and survives only in tests, matching its new header comment. AudioEngine::applyBackendAudioCapabilities has exactly two callers (MainWindow_Session.cpp:2746, the new test).
• Couldn't check: anything runtime. No build, no ctest, no GUI, no radio. Every finding above is reasoned from the head checkout at /tmp/aetherclaude/pr-5438, not reproduced. In particular I could not confirm whether icom_backend_test's CivCase block (:2400+) also breaks — it depends on FakeIc705's broadcast-reply behavior against the hardened parseModelIdReply, which I can only settle by running it.

6. Recommendation

Request changes, narrowly. The fix for #5164 is right, well-reasoned, and the new socket-free test genuinely fails against unfixed code — this is a good change. But it lands with a stale assertion in a registered target that the PR gate does not run, so the breakage surfaces on main rather than here, and it drops a diagnostic whose deleted comment says exactly why it existed. Concrete next step: build and run icom_backend_test locally, update (or knowingly retire) the :2328-2385 block and whatever else in :2400+ moves, and restore the pinned-address mismatch warning inside adoptCivIdentity. The modelId bridge field is a small maintainer call, not a blocker.

Thanks for a clear diff — the comment discipline on the deleted state machine made this much easier to audit than it would otherwise have been.

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

Reviewed at head 10a9ee63. Built the PR on Windows/MSVC (Ninja, Qt 6.10.3) and ran icom_identity_test with real stdout, plus a mutation check and a targeted probe of the wake framing path.

Two findings from the previous review do not survive contact with tests.cmake — please don't spend time on them. Details in "What I tried to break" below.

1. Issue fit

The #5164 fix is right. Rebinding the TX-audio lifecycle to capabilitiesChanged via the idempotent AudioEngine::applyBackendAudioCapabilities, and identifying from the 19 00 payload instead of modelForName(), is exactly the "one idempotent helper … do not infer hardware identity from the nickname" direction the issue asked for. Every acceptance criterion maps to a hunk except the last — live dummy-load proof (fresh TX bytes, nonzero forward power, safe unkey). The body doesn't claim it; worth saying so plainly rather than leaving it unmentioned.

2. Scope

No CHANGELOG.md entry — correct.

Governance: the wake feature is cleared, and I want to be explicit about why. At first read it looks like a large unratified feature bundled into a bug fix. It isn't: #5349 carries your own ruling — "I support this for wake" as an option, with sleep-on-disconnect explicitly ruled out because "a remote user can lock themselves out of their radio". This PR implements precisely that: opt-in, default off, wake-only, no power-off on disconnect. No RFC needed. The only process note is that the wake half has no linked issue of its own (#5349 is referenced as "related" only), which makes it harder to find later.

3. Blockers

1. An IC-9700 at a non-default CI-V address silently gets the wrong wake frame

populateFamilyParams inserts icom.wakeModelId only when civSelection() == Model. In Auto and Custom it is absent, so modelId == 0, which bypasses the powerOn profile requirement in power.wake. The only 9700 rescue is the hardcoded address == 0xA2 && advertisedCivAddress() == 0xA2, so a 9700 whose CI-V address was changed misses it and falls through to standard{}.

I drove power.wake through the real backend on the PR head. Same radio, only the address differs:

# IC-9700 at DEFAULT 0xA2 — correct
PROBE frame len=470: fe fe fe fe ... (150x fe) ... a2 e1 18 01 fd

# IC-9700 at CUSTOM 0xB0 — wrong
PROBE frame len=20:  fe fe b0 e0 18 01 fd
PROBE started=1 err=

Zero preamble bytes and controller E0 instead of the measured 150xFE / E1. It returns started=1 with no error, the radio never wakes, and the 20 s deadline expires. This defeats the exact hardware evidence @w5jwp contributed in #5360, in a configuration this file's own comments call out as real ("on a shared CI-V bus … the operator SELECTING WHICH DEVICE to talk to").

Suggested direction: carry wakeModelId for Custom/Auto as well, or key framing off the advertised/identified model rather than the literal 0xA2 — and refuse rather than silently sending standard framing when a 9700 is indicated but unprofiled.

2. Mid-session Icom configuration warnings now render into a hidden widget

Moving configurationWarning from statusBar()->showMessage(message, 15000) to m_connPanel->setStatusText(message) is sound for connect-time advice, and the rationale (don't cover the Connect control) is good. But setStatusText is a bare m_statusLabel->setText() with no visibility guarantee, and m_connPanel->hide() runs on the connected edge (MainWindow.cpp:6070).

configurationWarning also carries mid-session warnings — the out-of-band tune refusal (IcomCivBackend.cpp:3594) and the DATA MOD-input advisory (:1636, whose comment says it exists to "NAME THE REMEDY, because this client deliberately will not apply it unasked"). Those now go somewhere the operator cannot see. Routing by connection state, or keeping showMessage while connected, would preserve both goals.

This one is a judgement call — if you'd rather keep it uniform, say so and I'll defer.

4. Nits (non-blocking)

• profileMap()'s new modelId is genuine bridge surface documented only in docs/automation-bridge.md; it belongs in the body's change list.
• wakeIcomRadio connects extensionResult as DirectConnection, calls invokeExtension, then disconnects and reads sent — assuming a synchronous reply. IRadioBackend.h:797 documents the opposite ("A synchronous QVariant return would have to block or fabricate a local value against an async backend"). Safe today because the path is gated on m_family == "icom" and that backend replies inline, but it's a trap if it ever defers. An assertion or a comment naming the coupling would pin it.
• onConnectionError early-returns during wake before the qCWarning(lcProtocol), so wake-path connection errors leave no log line.
• No test injects a mismatched identity after wake, so the "The radio identified as a different model." branch — which disconnects an otherwise-connected radio — is uncovered. Every completion case injects a matching reply.
• IC-705 physical wake untested; the body says so, which is the right call.

5. What I tried to break (and failed)

• The previous review's Blocker 1 (icom_backend_test breaking on main) is refuted. That target sits inside a CMake bracket comment, tests/tests.cmake:584-606, retired under the #5254 fake-peer remediation — and it was already commented out on origin/main before this PR. It is not registered, cannot fail CI, and per AGENTS.md a bracket-commented test isn't coverage either way. The stale assertions are in dead code; at most a nit, and arguably just history.
• Its Nit 1 (the new test writing the developer's real settings store) is also refuted. icom_identity_test.cpp:108-109 sets AETHER_SETTINGS_DIR from a QTemporaryDir before AudioEngine is constructed, so it is properly isolated.
• The new test is not a rubber stamp — I inverted it. Replacing the wake TX guard if (m_keyed || m_tuning || m_pendingPttIntent.value_or(false)) with if (false) and rebuilding produced FAIL: wake refuses an active transmitter (2 failures, exit 1). Restored: icom_identity_test: 0 failure(s), exit 0, on Windows/MSVC.
• Principle VI holds. Wake sends 18 01, never a keying command, and refuses while m_keyed || m_tuning || m_pendingPttIntent. The commit trailers are apt.
• addPermanentWidget vs #3500. #3500 (a08e66f9) fixed width/minimum-size clipping, not widget placement, and updateStatusBarMinimumWidth() still runs. No regression there.
• Test-boundary preflight is clean. The PR adds no socket-owning test and no fake peer; icom_identity_test never calls session.start() — frames enter via onCivFrame.
• Could not verify: anything needing a real Icom. The wake path is unreachable in demo mode (SimBackend isn't Icom and wakeIcomRadio is family-gated), so the checkbox's GUI behaviour is reasoned from code plus your hardware evidence. Blocker 1 is reproduced at the backend level, not on a physical 9700 — if the framing fallback is deliberate for some reason I've missed, I'd rather hear it than have you work around it.

6. Recommendation

Request changes, narrowly — Blocker 1 only; Blocker 2 is yours to rule on.

The #5164 fix is correct and genuinely well-tested, and the wake feature is properly scoped, default-off, TX-safe and maintainer-sanctioned. But it silently sends the wrong frame to the one model whose framing was hardware-measured, in a configuration the code itself describes as common — and the frame dumps are above.

_{Reviewed by Claude Opus 5 on aurora13 for @nigelfenton. Built and ran the PR head; frame dumps and the mutation check are from that build.}

Operator-requested second opinion at 10a9ee63d94a72ca516f7322a950e4b08052f0e9. Request changes for two additional reproduced P2 defects, detailed inline: native CW cancellation is lost after identity withdrawal, and the permanent full-width status container hides transient status messages.

The identity/TX-audio approach addresses #5164: the CI-V model-ID payload selects capabilities independently of the nickname and operating address, and late capability changes reapply audio routing. Live dummy-load acceptance remains unverified in this review. Optional wake is explicitly claimed in the title/body and related to #5349.

Scope

All 32 changed files fit these groups. No governance, changelog, or frozen CI gate changes. Author-reported hardware evidence was not independently repeated.

Verification

• Built the exact-head macOS application and focused targets with Qt 6.11.1, RelWithDebInfo; ASR, RADE, DSTAR and DFNR disabled locally.
• All 10 focused Icom CTests passed after restoring the temporary probes: identity, family, CI-V, scheduler, protocol, scope, audio, meters, memory and power derivation (12.68 seconds).
• A socket-free probe through real RadioModel/CwxModel/backend code failed on missing CW abort after identity conflict. Temporarily aborting before capability withdrawal made the same assertion pass; restored both production and test sources, rebuilt, and reran the original suite.
• Drove the exact-head application offscreen through an isolated authenticated local bridge, with isolated settings, muted PC output, TX disabled and outbound IP traffic denied. Verified the owned PID, disconnected state and zero slices; clicked the RX step control, observed Step: 250 Hz in QStatusBar.statusMessage, and captured the status bar without that text. Stopped the owned instance afterward.
• Engine-boundary strict check passed (102 tracked legacy warnings, zero blocking findings); test registration, frozen CI gate, generated bridge docs and whitespace checks passed.
• All five current CI checks pass, including actual Linux/macOS/Windows build steps. All five commits have valid GitHub signature verification. The Icom identity test is not run by the per-PR CI gate; it was run locally here.

PR base/merge base: 50d70ebe9fdc4d6f01171b5cb17479bc89537be2. Trusted current-main governance snapshot: d58e2b8a94af82f273f60010df17b080e6b2d907; manifest PASS, Constitution mirror matches. Checked intervening main changes for stale overwrites in these paths; none found.

I am not duplicating the existing custom-address IC-9700 wake and hidden connection-panel warning threads. The new status-bar finding affects other showMessage() callers and remains even if the existing warning-routing issue is corrected.

No physical wake, live RF/TX, microphone, forward-power/unkey acceptance, full-suite or sanitizer-runtime test was performed. The CW probe establishes missing cancellation dispatch, not measured continued RF. No additional nits. Please fix the two reproduced paths and cover their regressions; required human CODEOWNERS approval remains separate.

Reviewed with Codex for @Ozy311.

Reviewed at head 10a9ee63, but the load-bearing part of this review is the one thing the three earlier passes could not have done: I merged this branch with current main and built the result. It does not compile. Everything below the scope table is new; I have deliberately not re-litigated the IC-9700 custom-address wake framing, the hidden connection-panel warning, or the CW-cancellation finding, which belong to their existing threads.

1. Issue fit

Yes on #5164. Rebinding the TX-audio lifecycle to capabilitiesChanged through the idempotent AudioEngine::applyBackendAudioCapabilities, and identifying from the 19 00 model-ID payload instead of modelForName(), is exactly the "one idempotent helper … do not infer hardware identity from the nickname" direction the issue asked for. Every acceptance criterion maps to a hunk except the last (live dummy-load proof of fresh TX bytes / nonzero forward power / safe unkey), which the body correctly does not claim.

The issue thread's two tightening asks are both satisfied, and I checked them rather than assuming:

• AppSettings::save() per capability edge — MainWindow_Session.cpp:2750-2753 writes only inside connected && pcAudioRequired && !savedPcAudio, so an unchanged value does not re-open the #4273 non-atomic write race.
• notePcAudioEnabled() repeated with an unchanged value — it does re-enter checkModInput() on every edge, but that path dedupes on m_lastModInputWarning (IcomCivBackend.cpp:1618-1620), so no repeated DATA OFF MOD advisory.

2. Scope

No CHANGELOG.md entry — correct. Test-boundary preflight is clean: the PR adds no socket-owning test and no fake peer. icom_identity_test constructs real IcomCivBackend / IcomSession / AudioEngine / RadioModel objects but never calls session.start(); frames enter through onCivFrame (tests/icom_identity_test.cpp:32-41), and AETHER_SETTINGS_DIR is pointed at a QTemporaryDir at :107-108 before AudioEngine is constructed.

3. Blocker

1. Merged with current main, this branch does not compile — and main's own CI would be the first thing to find out

mergeable is CONFLICTING. That alone is routine; what is not routine is what is on the other side of the conflict. Two commits landed on main after this PR's merge base 50d70ebe:

• 4bf9c5a6 — fix(icom): preserve finite AX.25 transmit audio over RS-BA1 (#5311)
• 6797007f — fix(icom): Restore durable memories and safe synced recall

#5311 added tests/icom_ptt_authority_test.cpp, a registered CTest (tests/tests.cmake:638-643, not bracket-commented), and it calls the function this PR removes:

tests/icom_ptt_authority_test.cpp:96:    const IcomModel* ic705 = modelForCivAddress(0xA4);
tests/icom_ptt_authority_test.cpp:199:   const IcomModel* ic9700 = modelForCivAddress(0xA2);

I merged pr5438-review into origin/main in a scratch worktree, resolved both conflicts conservatively (combining the TX-audio gate, keeping both verb blocks, keeping both test registrations) and built:

FAILED: CMakeFiles/icom_ptt_authority_test.dir/tests/icom_ptt_authority_test.cpp.o
tests/icom_ptt_authority_test.cpp:96:30: error: 'modelForCivAddress' was not declared in this scope
tests/icom_ptt_authority_test.cpp:199:31: error: 'modelForCivAddress' was not declared in this scope

This PR does the mechanical modelForCivAddress → modelForId rename in icom_family_test, icom_meters_test, icom_memory_test and icom_power_derivation_test — correctly. It could not have renamed the one in icom_ptt_authority_test, because that file did not exist when the branch was cut.

Why the five green checks do not cover this. The Linux build job runs cmake --build build -j$(nproc) (.github/workflows/ci.yml:195) — all default targets, tests included — so this is a build-job failure, not merely a full-suite one. And branch protection deliberately does not require branches to be up to date (ci.yml:22-25 explains why), so nothing forces a re-run against the current tip. The breakage lands on main.

The second conflict is semantic, and resolving it the obvious way silently reverts #5311. Both sides edit the same submitTxAudio gate:

// merge base
if (m_tuning || !m_keyed) {
// this PR
if (m_tuning || !m_keyed || !m_model->hasTransmit) {
// main, after #5311
if (m_tuning || !txAudioGateOpen()) {

txAudioGateOpen() (IcomCivBackend.cpp:3455-3461) is #5311's bounded key-on window — the thing that keeps the AX.25 FCS and postamble from being dropped. Taking "ours" here compiles fine and quietly undoes that fix. I resolved it as if (m_tuning || !txAudioGateOpen() || !m_model->hasTransmit), which is what I believe you want, but it is your call and it needs a test.

Concrete next step: merge main in, update icom_ptt_authority_test's two modelForCivAddress calls to modelForId, combine the TX-audio gate deliberately, and re-run the focused Icom set plus icom_ptt_authority_test on the merged tree. I ran the pre-merge set here and it is clean (below), so this is genuinely the only thing standing between the branch and a build that holds on main.

4. Nits (non-blocking)

1. IcomSettings.h:32-35 — the two new declarations were inserted between the username() doc comment and username() itself, so "The operator's network username on the radio. NOT a secret…" now reads as documentation for wakeOnConnect(). Suggestion inline.
2. RadioModel.cpp:1210 — wake completion is defined as canTransmit, not "identity arrived". Every model in kModels transmits today, so this is latent, but an RX-only Icom (an IC-R receiver) would be force-disconnected by the 20 s deadline after a wake that actually succeeded, via finishRadioWake(..., false). A comment naming the coupling, or keying completion off m_civReported != 0, would pin it.
3. ConnectionPanel.cpp:1153 — "Wake on connect" is visible and enabled for every family. I confirmed it on the bridge in a session where only a FLEX-8600, a Hermes-Lite 2 and the demo simulator were discovered: visible: true, enabled: true. Only the accessible description says "Icom"; the visible label does not. A FLEX-only operator sees a control that cannot do anything.
4. IcomProtocol.cpp:459 — the comment ("civ at record offset 0x52, after the 0x42-byte envelope header") is arithmetically right but reads as a contradiction next to pkt[0x94], especially since parseCapabilitiesName uses absolute 0x52. Bounds themselves are fine: startsWith pins pkt.size() == 0xA8, and 0x94 < 0xA8.

5. What I tried to break, and could not

• Ambiguity latch as a permanent TX lockout. m_civAmbiguous = true disables transmit for the session and adoptCivIdentity returns early forever after — but it is cleared on both connectRadio (:842) and session reset (:977), so a shared-bus collision does not survive a reconnect. Held.
• Repeated capability edges duplicating capture or thrashing settings. Both tightenings from the issue thread are implemented; see §1. Held.
• OOB read in the new parseCapabilitiesCivAddress. Size-pinned, index in range. Held.
• The pre-merge Icom suite. Built the PR head on Arch/GCC 15/Qt 6.10 RelWithDebInfo and ran the full icom_ set offscreen: 16/16 passed in 13.79 s, including icom_identity_test (13.48 s). No local failures to attribute.
• Bridge session, demo simulator only. Isolated AETHER_SETTINGS_DIR + scratch HOME, AETHER_AUTOMATION_NO_TX=1, explicit socket aethersdr-pr5438, own PID. connect list offered DEMO-0001; get radio returned {"model": "AetherSDR Demo", "serial": "DEMO-0001", "transmitting": false}. The operator's FLEX-8600 was discovered and never touched.
  • Checkbox placement claim confirmed: Connect to last radio on start up at y=618, connectionWakeOnConnect at y=652 — directly beneath, as the body says.
  • Persistence claim confirmed across a process boundary: toggled it on, killed the process, relaunched against the same store, checked = true.
  • Sim path not regressed by the rewiring: two disconnect/reconnect cycles, orphanCount: 0, transmitting: false throughout.
• Corroboration for the existing hidden-warning thread (not a new finding, but the bridge settles the mechanism): while connected, invoke connectionWakeOnConnect returns {"error": "refused: 'connectionWakeOnConnect' is not visible", "hidden": true} — the whole connection panel is hidden on the connected edge, so everything routed to setStatusText is unreachable mid-session. Worth noting that adoptCivIdentity's ambiguity notice, "Conflicting CI-V identification replies. Transmit is disabled; select the radio's CI-V address and reconnect." (IcomCivBackend.cpp:1296-1298), goes through that same configurationWarning path. That one is a transmit-disabled notice, which raises the stakes on that thread beyond the tune-refusal and DATA MOD advisories already cited.
• Generated-docs drift: tools/gen_bridge_docs.py --check → ok: docs verb table matches the registry (71 verbs).
• Could not verify: anything needing a real Icom — the wake path is family-gated and unreachable in demo mode. I did not independently re-run the IC-9700 frame dumps or the CW-cancellation probe from the other two reviews; I have no evidence against either.

6. Recommendation

Request changes, on Blocker 1 only. The #5164 fix is right, the identity state machine is well-commented and survived the attacks I could mount against it, and the new socket-free test is real coverage rather than a rubber stamp. But the branch is three days stale against a main that grew a registered test for the exact subsystem this PR rewrites, and the merged tree does not compile — with the added trap that the second conflict can be "resolved" into a silent revert of #5311. That is a merge-and-fix, not a redesign.

_{Reviewed by Claude Opus 5 for @jeremy_fielder. Merged, built and ran the branch locally on Arch Linux; the compiler output and bridge JSON above are from that run.}