feat(seam): health that survives disconnection — the verb #5414 was missing

[on8st]

The finding this PR exists to answer

Every health reading this application can take is conditional on a live
session. RadioModel::backendHealthSnapshot() is
m_backend ? m_backend->healthSnapshot() : HealthSnapshot{} — and while that
backend does outlive a disconnect (it is built in setupBackend(), called from
the RadioModel constructor and from rebuildBackendForFamily(), not from
connectToRadio()), what it reports does not. Each family blanks its rows
when the link is not delivering, precisely so a stale figure cannot masquerade
as a current one. So a disconnected app answers health with nothing:

{"cmd":"health"} → {"connected": false, "ok": true, "rows": []}

For most questions that is correct — a radio you are not talking to has nothing
to say. For three it is exactly backwards:

• is another client holding this radio?
• is it powered and reachable?
• what is its PA temperature while somebody else has the stream?

The premise of all three is that we are not connected.

Why a capability flag cannot substitute, which is the crux

docs/HERMES.md's "For coding agents — keep bring-up inside the family
backend" permits one exception to keeping work inside
src/core/backends/<family>/: declare a RadioCapabilities flag and gate on it.

That shape cannot be applied here, and the reason is structural rather than
inconvenient. RadioCapabilities is produced by a connected backend. In the
two states this feature exists for — nothing connected, and another client
holding the radio — there is no capability record worth reading. A capability
gate is the right shape for "this radio cannot do X" and the wrong shape for
"nothing has asked this radio anything yet."

That is the gap, and the same section names what to do about it:

When the seam itself is missing a verb: that is a separate,
capability-shaped PR, not a drive-by in the wire patch. Name the other
families in the PR body and prove they still take the Flex/Icom path.

This is that PR. It designs the missing verb; it does not relocate a violation.

What it does

The declaration moves off the radio and onto the family.

New	What it is
src/core/backends/OfflineHealthSource.h	IOfflineHealthSource — aim it, is it aimed, note demand, give rows. Carries no wire concept beyond an address, on purpose: the moment it carries two it has started to describe one family's protocol. Plus OfflineHealthRegistry, a family → factory map.
src/core/backends/HealthSnapshotMerge.h	mergeHealthSnapshots(), family-neutral, so AutomationServer does not include a family header to merge two snapshots. hl2MergeHealth forwards to it — moved, not copied, so the HL2 tests keep pinning the same function rather than a re-typed twin.
tests/offline_health_registry_test.cpp	Socket-free by construction — it injects the transport.

Changed	How
IRadioBackend	setOfflineHealthSource() — virtual, default no-op. The model hands every backend the same interface pointer and never asks what it built. Passing null is how the model takes the borrow back before destroying what was lent.
Hl2TelemetryService	Implements the interface, and declares "hl2" from Hl2TelemetryService.cpp. That is the only place the family is named.
Hl2Backend	Overrides the seam setter and dynamic_casts to its own concrete type inside its own directory, where knowing your own types is tautological. Also publishes RAD:PATEMP from the stream-free reading whenever the in-band path is not delivering, so the needle stops holding a figure from a session that ended.
RadioModel	Owns a std::unique_ptr<IOfflineHealthSource> tagged with the family that built it, null unless that family declared one. Asks the registry.
AutomationServer	doHealth() merges when and only when a source exists, in-band winning on collision; telemetry target <ip> aims it without connecting.

The address names the radio, and discovery names its family

telemetry target <ip> resolves the address against the same discovery table
connect list reads, and builds that radio's family's instrument.

It used to gate on m_family instead — the family of the session you are
already in. That is set only by connectToRadio(), so on a fresh app it was the
default and every aim was refused; the only cure was to connect to the radio
first, which is the write into somebody else's session this verb exists to
avoid. Aiming still never connects, never writes, and never changes the
session's family. An address discovery cannot see is refused rather than probed
on a guess — falling back to the session's family would quietly reintroduce the
cross-family leak the declaration gate closes.

Both prohibited constructs are gone, not carried across

• The two m_family != QLatin1String("hl2") tests are deleted. The gate is
  OfflineHealthRegistry::declaredFor(<family>) — the same move refactor(models): gate family verbs on the declared namespace (#5262 M1) #5618 made for
  extension namespaces, and for the same reason: it reads a declaration instead
  of hard-coding who is expected to have made it.
• The dynamic_cast<hl2::Hl2Backend*> in setupBackend is deleted. Tracking: backend architecture review (IRadioBackend seam + multi-radio) — open issues and new findings #5554
  §2.8 already lists that shape as a seam leak to retire.
• src/models/RadioModel.h includes no family header and names no family.

The other families still take their own path

Family	What it constructs	What health returns	telemetry target
flex	nothing	backendHealthSnapshot() only, byte-identical	refused, with a reason
icom	nothing	unchanged	refused
sim	nothing	unchanged	refused
anan	nothing	unchanged	refused
rtl	nothing	unchanged	refused
hl2	the service	merged, in-band winning	accepted

offline_health_registry_test asserts the Flex and Sim columns directly,
including that a refused aim constructs nothing, and that a second declaring
family gets its own instrument rather than the first one's.

Pre-PR grep

docs/HERMES.md's pre-PR grep finds two hits, both src/models/RadioModel.*,
and both are the point of the PR rather than an accident in it: this is the
change that is allowed to touch the shared model, because it is the separate
capability-shaped PR the rule asks for. Everything above is the explanation the
rule requires.

Honest gaps

• The linkage risk is real and is why the first assertion exists. A
  self-registering translation unit that nothing references can be dropped from
  a static archive with no diagnostic, and the feature would then not exist while
  every other test still passed. The chain that keeps it alive is written at the
  registrar. The test asserts the declaration is present rather than trusting it.
• Reading health arms the probe, and that is deliberate. The Radio Health
  dialog's 500 ms refresh calls offlineHealthRows() → noteOfflineDemand(),
  which renews a 5 s demand window; a health read does the same. So an aimed
  radio is polled at 1 Hz for as long as something is watching, and goes quiet
  on its own within the demand window when nothing is. There is no way to read
  this health without asking for it — a window showing health is someone
  asking. telemetry target off stops it and releases the source. Documented in
  docs/automation-bridge.md.
• Not verified on hardware. No radio was connected and nothing was
  transmitted. The connected-and-stalled and held-by-another-client paths are
  reachable by construction, not by measurement.
• IOfflineHealthSource has exactly one implementer today. A one-implementer
  interface is a design bet, not a proven abstraction; the bet is that "health
  that survives disconnection" is not an HL2 peculiarity. The second-family test
  pins the behaviour the bet depends on, so the next family to declare one is a
  registration rather than a rewrite.
• Governance. No linked issue and no [RFC]. This adds a new seam interface,
  a registry, a timer, a second UDP socket and a new public bridge verb that
  third parties bind to — which GOVERNANCE.md would ordinarily want an RFC for.
  Flagged for a maintainer ruling rather than asserted as compliant.

[aethersdr-agent]

Issue fit

No fixes/closes #NNNN in the PR body — this is offered against its own stated intent (roadmap #15, and the "separate, capability-shaped PR" that docs/HERMES.md's coding-agent section asks for when the seam is missing a verb). Judged that way it does what it says: IOfflineHealthSource + OfflineHealthRegistry give the model a health path that is not conditional on m_backend, the dynamic_cast<hl2::Hl2Backend*> that would otherwise have lived in RadioModel is pushed down to Hl2Backend::setOfflineHealthSource(), and no family string appears above the seam (I grepped src/models/ and src/core/AutomationServer.cpp for "hl2" in the added lines — none). GOVERNANCE.md's RFC trigger is "any change to visual design"; the PR is careful to keep the Radio Health dialog out, but see Blocker 2 — it changes what that dialog renders anyway.

Scope

File(s)	What it changes	Claimed?	Verdict
OfflineHealthSource.{h,cpp}, IRadioBackend.h, HealthSnapshotMerge.h	the new seam: interface, registry, family-neutral merge	yes	in scope
RadioModel.{h,cpp}	owns/releases the source, gates on the declaration	yes	in scope
AutomationServer.{h,cpp}, docs/automation-bridge.md	new bridge verb telemetry + generated doc row	yes	new public surface — maintainer call (a third party can now bind to it)
hl2/Hl2TelemetryPoller.*, Hl2TelemetryService.*, Hl2TelemetryCadence.h, Hl2TelemetrySource.h, MetisProtocol.*	the HL2 implementation and the discovery-reply decode	yes	in scope
hl2/Hl2Backend.{h,cpp}	service borrow, stall clock, poll-state tick, in-band rows blanked when not Streaming	partly	the blanking is a behaviour change to an existing snapshot — see Blocker 2
docs/architecture/hl2-stream-free-telemetry.md	design note (405 lines)	yes	in scope
CMakeLists.txt, tests/tests.cmake, 8 test files	build + coverage	yes	in scope
docs/automation-bridge.md blank-line churn at 4271	inside the <!-- BEGIN GENERATED VERB TABLE (tools/gen_bridge_docs.py) --> block	—	generator artifact, not hand-edited

No CHANGELOG.md entry — correct. Nothing in the diff is unrelated to the stated change.

Socket tests (disclosure, not a finding)

• tests/hl2_telemetry_wire_socket_test.cpp — binds one IPv4 UDP listener on 127.0.0.1:1025 (ShareAddress); sends to 127.0.0.1 and to 192.0.2.1 (TEST-NET-1). The subject is our own poller, not a synthetic radio peer — no Fake* firmware anywhere. It is off the default graph behind option(AETHER_ENABLE_HL2_TELEMETRY_SOCKET_TEST … OFF), still add_test-registered when enabled, and SKIP_RETURN_CODE 77 on a refused bind. CI does not run it. That is the shape hl2_tx_loopback_test already uses and it is disclosed in both the test header and the tests.cmake block.
• hl2_telemetry_service_test is socket-free by construction (no target + broadcast fallback off ⇒ the poller binds nothing) — I checked Hl2TelemetryPoller::applyCadence(), which drops the socket whenever currentIntervalMs() <= 0, and pollDestination() returns null in that configuration. The claim holds.

Blockers

1. temperatureC is exempt from the very blanking the hunk exists for, and it wins the merge. — inline at src/core/backends/hl2/Hl2Backend.cpp:4570.

The new comment at 4422 says a frozen in-band reading presented as live "is the exact failure the feature was built to expose, so it must not be the feature's own output", and every t.* row now yields when inBandLive is false. temperatureC does not: it is driven from m_havePaTemp/m_paTempC, which publishTelemetry() sets at 5480–5482 and nothing ever clears (grep: those two members appear only at 4571, 5480, 5482 and their declarations). So on a stall or after a disconnect the merged health reports temperatureRaw = the fresh port-1025 count and temperatureC = the pre-stall smoothed °C — a valid value, so it wins the merge over anything the poller could ever supply — and they can disagree by an arbitrary amount. °C is the row an operator actually reads. forwardPowerPeakW got this right (gated on t.forwardPowerRaw); this one was missed.

2. The Radio Health dialog is an unmerged consumer of the snapshot this PR changed. — inline at src/core/backends/hl2/Hl2Backend.cpp:4423.

The design note states the dialog "reads backendHealthSnapshot() alone and therefore says 'Not connected.' in exactly the states this feature exists for", and files it as a third, RFC-gated change. That is not what happens after this diff. src/gui/RadioHealthDialog.cpp:113 reads backendHealthSnapshot() with no merge, and formatValue() renders an invalid QVariant as —. The snapshot is not empty (the connected/model/keyed rows remain), so the "Not connected." early-out does not fire — the dialog stays populated and now shows — for firmware version, ADC overload, TX inhibited, PTT, TX FIFO fill, TX pacing fault, temperature raw, bias current, forward/reverse raw + W, peak W and SWR whenever the link is not Streaming, where it previously showed the last in-band readings. That includes every disconnected session and every ≥2.5 s stall. Reasoned from code; I could not run the GUI.

I think the blanking is the right call at a merged consumer and wrong at an unmerged one. Either the dialog has to merge in the same PR (which is the visual-design change GOVERNANCE.md wants an RFC for), or the blanking has to be scoped to the merge point rather than applied inside healthSnapshot(). Maintainer call, but the PR body should not say the dialog is untouched.

Nits (non-blocking)

• telemetry target <ip> accepts any address. AutomationServer.cpp:6893 rejects only non-literals; 8.8.8.8, a multicast group, or a neighbour's address is accepted and gets a 60-byte UDP datagram every second for as long as anything reads health (the demand window is 5 s and every health call renews it). The PR removed the broadcast fallback specifically because "the fallback could … put datagrams near a host that must not be polled" — the unicast case has the same property and no guard. A private/link-local check, or at least a qWarning naming the target once, would close the gap.
• A stale streaming bit can latch HeldByOther onto a radio nobody is using. Hl2Backend.cpp:681 derives heldByOther from reply->streaming, and Hl2TelemetryService::setTarget() drops the cached reply only on a target change, not on disconnect. A poll taken while we were stalled carries our own run bit; after disconnecting from the same radio, telemetryLinkState() reads that reply and reports HeldByOther, and radioInUse renders true. It self-corrects on the next poll — but HeldByOther is demand-gated, so it corrects only once something reads health again.
• Nothing resets the service's link state when the backend driving it is destroyed. Hl2TelemetryService keeps d->state and re-pushes it every second forever. A backend torn down while Streaming leaves the service at interval 0 until a new backend's tick arrives. Today that window is bounded (an hl2→hl2 rebuild constructs the new backend's tick immediately; an hl2→non-hl2 switch releases the source), so it is latent rather than live.
• be16() does not mask to 12 bits. The comment says the top nibble is zero on this gateware; a & 0x0FFF would make the decode independent of that assumption for the same cost.

What I tried to break

• Ownership of the borrowed pointer. m_offlineHealth is declared after m_backend, so member destruction order would destroy the source first — but ~RadioModel() calls teardownBackend() in its body (RadioModel.cpp:2834), which drops the backend before any member runs, and releaseOfflineHealthIfUnused() refuses while m_backend is non-null. The invariant the header states holds on every path I could find, including telemetry target off on a connected session and the rebuildBackendForFamily → teardownBackend → setupBackend ordering. Survived.
• Cross-family leakage. Tried telemetry target from flex/icom/sim: OfflineHealthRegistry::declaredFor() refuses before anything is constructed, hasOfflineHealth() stays false, doHealth() takes the un-merged branch, and offline_health_registry_test asserts all four. Survived — this is the failure the PR says it reproduced live, and the gate is real.
• Linker-dropped registrar. The stated chain (RadioModel::makeBackend → hl2::Hl2Backend → dynamic_cast<Hl2TelemetryService*> → the TU with the out-of-line key-function destructor) holds, and the test asserts the declaration rather than trusting it. Survived.
• Bounds on the new decode. Walked every pkt.size() > N guard against the highest byte each branch touches (0x1a/0x1b/0x23/0x24/0x26/0x28) — all correct, including the two-byte be16 reads. A short reply leaves the fields nullopt rather than reading past the span. Survived.
• Merge direction. Constructed the "winner declares a key but omits the value" case by hand: HealthSnapshotMerge.h inserts into values only from constFind != constEnd, so an absent value cannot erase the base's — and the backend relies on exactly that when it blanks. The ptt bool special-case (a plain false would have won and claimed the radio is unkeyed) is handled and pinned by hl2_telemetry_wire_test. Survived.
• Would the tests fail on the unfixed code? hl2_telemetry_wire_test asserts linkStateUpdateCount() >= 2 from a disconnected backend, which is only satisfiable by the 1 Hz tick the PR restored — deleting that timer fails it. hl2_link_state_alias_test keeps the old tick-to-tick predicate as a negative control. These are not implementation-echo tests.
• Could not check: the PR body (not supplied to me), so I cannot confirm it discloses the socket test or the dialog change; no build, no test run, no GUI — every finding above is reasoned from source in /tmp/aetherclaude/pr-5642, not reproduced at runtime. CI is green on all five checks for 6358bce, but ci.yml runs an -R-filtered subset and none of the eight new tests are in the gate.

Recommendation

Needs maintainer decision, with one change I'd ask for regardless. Blocker 1 is a straightforward fix inside this PR — gate temperatureC on inBandLive the way every neighbouring row now is. Blocker 2 is genuinely a judgement call: the diff quietly changes an existing UI surface that the PR's own design note reserves for a later RFC'd change, and the telemetry verb is new public surface in a PR that is otherwise seam work. The engineering underneath is unusually well-evidenced — the cadence, the stall clock and the merge rule are each pinned by a test that discriminates rather than echoes — so this is about scope and disclosure, not quality.

---

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

[on8st]

Rebased onto 87b80c65 at 43875cc0. Main's stream-free telemetry groundwork touches the same seam this PR extends; the conflicts were resolved by re-applying both sides, no side dropped. Full ctest 423/424 — the one failure is vkamp_connection_test, which fails the same way on an untouched tree (2 of 3 isolated runs here) and is unrelated. Localization check: two hits, both src/models/RadioModel.*, both already explained in the PR body; zero violations.

[aethersdr-agent]

CI on d0552394 — the failure is not in your HL2 logic, and it isn't the Copilot findings either (the temperatureC gate and the linkDown pole clear both look right, and the smoothing-pole point you found on top of the review is a genuine catch). It's a bookkeeping gate that fires on one line of this diff.

What failed

One job, one step:

• Static checks → aetherd touchpoint manifest (run 34744654456) — python tools/gen_touchpoint_manifest.py --check

Everything else on that commit is green or still running: Sanitizer option configures passed, and build / check-macos / check-windows were in progress.

Why

src/gui/RadioHealthDialog.cpp gained a new engine include:

#include "core/backends/HealthSnapshotMerge.h"

That is a new gui→engine touchpoint, and the aetherd burndown treats those as tracked state. tools/gen_touchpoint_manifest.py scans src/gui/ + src/main.cpp for quoted includes that resolve into src/core/ or src/models/, and --check fails on either of two conditions:

1. a live touchpoint with no valid semantic tag in docs/architecture/aetherd-touchpoint-tags.json (invalid_live_tags), or
2. docs/architecture/aetherd-touchpoints.md differing from what the generator would produce.

core/backends/HealthSnapshotMerge.h is a brand-new header, so it hits both: untagged, and absent from the committed table (whose totals line — N touchpoint headers … tagged, … converted — is now off by one too). The check is deliberately stdlib-only and full-tree, so it doesn't care that the header is a 40-line inline function.

Worth noting: src/models/RadioModel.h including core/backends/OfflineHealthSource.h does not trip this — the scan only walks the UI roots, and models/RadioModel.h is already a tracked touchpoint. It really is just the one dialog include.

Fix — two steps

1. Tag the header in docs/architecture/aetherd-touchpoint-tags.json. The tag must match ^(universal|ui-support|(vendor|mixed|peripheral)\(<family>\))$. Given the header's own opening comment ("Family-neutral, because two consumers now need it and one of them … must not include a family header to get it"), universal is the honest classification — same bucket as core/backends/IRadioBackend.h. Something like:

"core/backends/HealthSnapshotMerge.h": {
  "tag": "universal",
  "note": "The snapshot merge rule, family-neutral by construction: a key the winner declares but omits from `values` means 'not reported' and must not erase a base value. Moved out of backends/hl2/Hl2TelemetrySource.h (which keeps hl2MergeHealth as a forwarder) because AutomationServer::doHealth() and RadioHealthDialog both need it and neither may include a family header. Names no family.",
  "split": "",
  "confidence": "high"
}

2. Regenerate the table — don't hand-edit it, the file carries a GENERATED FILE banner:

python tools/gen_touchpoint_manifest.py
python tools/gen_touchpoint_manifest.py --check   # should print "manifest up to date"

Commit both docs/architecture/aetherd-touchpoint-tags.json and docs/architecture/aetherd-touchpoints.md. No status entry is needed — render() defaults an absent key to unconverted.

Order matters: the tag check runs before the staleness comparison and returns early, so if you regenerate without tagging first you'll get a second red run with the require a valid semantic tag message instead.

On the Copilot review

None of the four findings caused this, but the architectural direction in them is what introduced the include: moving the merge above the family seam so RadioHealthDialog could merge instead of rendering em dashes is exactly the "either it merges here, or the blanking moves to the merge point" resolution the blocker asked for. The manifest just wants that new seam crossing written down. The telemetry target <ip> validation nit and the HeldByOther-after-disconnect nit are still open on their own terms — neither blocks CI.

Nice work on this one — the m_havePaTemp/m_paTempC clear on linkDown was a real find beyond what the review asked for, and it's the kind of thing that would otherwise have shown up months later as "my radio reads warm right after I plug it in."

---

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

[on8st]

Right on all counts, and thank you for chasing it to the line — the include is the break, and it is mine.

Fixed at ade48a59. core/backends/HealthSnapshotMerge.h is tagged universal, which is what the header claims for itself in its own opening comment: family-neutral by construction, names no family, and it exists precisely because two consumers need the rule and one of them must not include a family header to get it. Same bucket as core/backends/IRadioBackend.h. Your suggested note is close to what went in; I trimmed it only to match the file's sentence shape.

Table regenerated with tools/gen_touchpoint_manifest.py, not hand-edited — totals moved 216→217 (184→185 core) and --check is clean locally.

Two notes for the record:

Your point about src/models/RadioModel.h is right and worth keeping, because it is the thing a reader would get wrong: the scan walks the UI roots only, and models/RadioModel.h is already a tracked touchpoint, so its OfflineHealthSource.h include does not add one. It really was just the dialog.

I nearly made this worse. My first pass rewrote the tags JSON through json.dump, which reformatted all 1,346 lines for a six-line addition and would have buried the change in noise. Reverted and inserted in place; the diff is 6 lines in the JSON and 2 in the table.

[on8st]

DRAFT — not posted. For the #5642 PR body or a comment on it.

Prepared 2026-09-14. Hand-check the frequency figure before posting: the
"six PRs in 48 hours" number came from a sibling agent's survey, not from
this session's own measurement. Everything else below is measured here.

---

The touchpoint manifest conflicts are structural, and cheap to end

docs/architecture/aetherd-touchpoints.md is generated by
tools/gen_touchpoint_manifest.py, and .github/workflows/static-checks.yml
enforces gen_touchpoint_manifest.py --check. The file contains exactly one
line that every touchpoint-adding branch is guaranteed to rewrite: the
**Totals:** line emitted by render().

The per-header table rows are not the problem. They are sorted, one row per
header, and each branch adds its own — git merges them cleanly, which is
observable in both conflicts below: the rows merged silently and only the
totals line came back as a conflict. A single line carrying three derived
counts cannot merge, ever, between two branches that each add a touchpoint.

Frequency. Six PRs touched this manifest in the last 48 hours. On
2026-09-14 it conflicted three times on our branches; #5642 and #5652 both
conflicted on that one line and on nothing else in the file.

Hand-merging it is not merely tedious — it produces a wrong number. In
both #5642 and #5652 the two sides offered were:

side	totals line
main	219 touchpoint headers (186 core, 33 models)
branch	217 touchpoint headers (185 core, 32 models)
regenerated	220 touchpoint headers (187 core, 33 models)

Neither side was correct, because each is a total computed over a tree that
is not the merged tree. Any resolution that picks a side ships a number that
is wrong by construction, and --check only catches it if the branch is
re-run after the rebase. This is the argument for never resolving this file
by hand — not style, arithmetic.

Remedy

Option 1 — a merge driver, so git stops asking.

In .gitattributes:

docs/architecture/aetherd-touchpoints.md merge=aetherd-manifest

and register the driver from whatever bootstrap script we already use, since
git config is not versioned:

git config merge.aetherd-manifest.name "regenerate the aetherd touchpoint manifest"
git config merge.aetherd-manifest.driver \
  'python3 tools/gen_touchpoint_manifest.py && cp docs/architecture/aetherd-touchpoints.md %A'

One caveat, stated plainly: a merge driver runs during the merge, and the
manifest is derived from src/ plus the two JSON sidecars, which are not
guaranteed to be merged at the moment the driver fires. So the driver removes
the conflict but the authoritative regeneration is still the post-merge one,
and --check in CI stays the guard. The failure mode is benign — the driver
writes a file that --check will either accept or flag — but it is not a
proof, and should not be sold as one.

Option 2 — make the conflict stop existing rather than be auto-resolved.

Stop putting three derived counts on one shared line in render(). Either
drop the totals from the generated file and let --check report them, or
emit them one count per line so two branches touching different modules do
not collide.

Option 2 is the one I would take. The totals line is the only part of this
generated file that every branch must touch, and it carries nothing that is
not recomputable in under a second. The table rows already demonstrate the
property we want from the rest of the file.

[ten9876]

Verdict

The registry mechanism itself is sound, and I tried hard to break it: I mutated declaredFor() open (9 checks fail, exactly as the body claims), walked every setupBackend() caller hunting for a path where a stale HL2 source could leak into a Flex session (there isn't one — teardownBackend() nulls m_backend first on every path), and drove a live demo session where telemetry target is correctly refused on both flex and sim with nothing constructed. That core holds up.

What does not hold up is a set of things around it that the body asserts and the code does not do. The most serious is that the new test is not socket-free — it binds a UDP socket and puts a real datagram on the wire, while the body, the file header and its tests.cmake block all say otherwise. Several others are consequences of this PR being the change that first activates the stream-free path: on main nothing calls noteDemand(), so these rows never reached a consumer and their defects were latent.

No linked issue and no [RFC]. The body flags that itself and asks for a ruling, which is right — but the ruling needs an accurate body first.

Scope

Nothing here is unrelated to the feature: no bundled build workaround, no drive-by reformat, no CHANGELOG.md entry. The scope problem is disclosure — the body was written against commit 1 and never updated for commits 3–4.

File / group	What it changes	Claimed in the body?	Verdict
backends/OfflineHealthSource.{h,cpp}	seam interface + family→factory registry	yes	in scope
backends/HealthSnapshotMerge.h	merge rule moved out of the HL2 header	yes	in scope — verified a forwarder, not a twin
IRadioBackend.h	setOfflineHealthSource(), no-op default	yes	in scope
hl2/Hl2TelemetryService.{h,cpp}	registrar, hasOfflineTarget()	yes	in scope
hl2/Hl2TelemetryService.cpp — leftOurOwnSession	drops a cached self-reply on leaving a session	no	from the last round; incomplete (blocker 2)
hl2/Hl2Backend.h	seam override + in-family dynamic_cast	yes	in scope
hl2/Hl2Backend.cpp — temperatureC gate, PA-temp pole clear	user-visible HL2 health change	no	undisclosed; see nits
models/RadioModel.{h,cpp}	owns the source; declaration gate	yes (the two explained grep hits)	in scope
AutomationServer.{h,cpp}	new telemetry verb, doHealth() merge	verb yes; address validation no	new public surface — maintainer call
gui/RadioHealthDialog.cpp	merges offline rows; 2 Hz demand driver	body states the opposite	blocker 6
CMakeLists.txt, tests/*	registration + new test	yes, as "socket-free"	blocker 1
docs/*	regenerated verb table + touchpoint manifest	implied	in scope — gen_touchpoint_manifest.py --check passes

The body's pre-PR grep claim ("two hits, both src/models/RadioModel.*, zero violations") is true — RadioHealthDialog.cpp is not in docs/HERMES.md's grep list — but it is true in a way that misses the GUI change.

Blockers

1. The new test binds a UDP socket and transmits — it is declared socket-free three times over. Inline on tests/offline_health_registry_test.cpp:106.

I did not take this on either side's word. Under an LD_PRELOAD shim on bind/sendmsg:

$ LD_PRELOAD=./shim.so ./build/offline_health_registry_test
[SHIM] bind AF_INET 0.0.0.0:0
[SHIM] sendmsg AF_INET 192.0.2.1:1025  63 bytes
offline_health_registry_test: all checks passed

The chain is synchronous and needs no event loop: setOfflineHealthTarget() calls source->noteOfflineDemand(), and noteDemand() (Hl2TelemetryService.cpp:153) calls poller->setSurfaceVisible(true) immediately — "Apply it NOW rather than waiting for the next tick". That makes the cadence hl2PollIntervalMs(NotConnected, true) = 1000, so applyCadence() news a QUdpSocket, binds it, and calls onPollTimer() inline ("do not make a stalled stream wait a full interval"), which writes the discovery datagram.

AGENTS.md puts three obligations on a new socket-owning test. All three are unmet, and two are actively contradicted: it is not disclosed in the PR body (listed as "Socket-free"), its tests.cmake block does not name the socket it binds (it says "Socket-free … the refusal paths construct no poller" — true of the refusal paths, false of the accepted one), and it does not fail fast or skip with exit 77 when it cannot bind — applyCadence() discards bind()'s return entirely, so in a sandbox that blocks raw UDP the test passes while doing nothing.

TEST-NET-1 is unroutable, so the practical harm is one 63-byte datagram per run to the default gateway. The declaration being false is the problem, on a bench whose whole §2.1a rationale was about datagrams reaching hosts nobody named.

My own disclosure: I ran this target during the preflight, having concluded from reading applyCadence() that the cadence would be 0. I had not yet read noteDemand(). That was wrong, and the automated pass caught it before I posted — but it means three runs of this test emitted that datagram from this machine.

2. health reports radioInUse: true during our own stalled session. Inline on Hl2TelemetryService.cpp:137.

healthRows() publishes put("radioInUse", "In use by another client", QVariant(r.streaming)) unconditionally, and Hl2Backend::healthSnapshot() publishes no radioInUse key at all (I grepped — zero hits), so the offline value always survives the merge. While connected-and-stalled, the poller runs at 2 Hz and the run bit in the reply it caches was set by us, so r.streaming is true. Both the bridge and the Radio Health dialog then tell the operator another client holds the radio — in exactly the stall state this feature exists to diagnose.

The leftOurOwnSession guard added here only drops the cache when leaving Streaming/StreamStalled, so it never fires while the stall is in progress. The guard is right; it just does not cover the case the PR's own headline question asks about.

3. telemetry target <ip> repoints the poller the connected backend is sharing. Inline on RadioModel.cpp:4705.

There is one Hl2TelemetryService instance — the model owns it and setupBackend() lends the same pointer to the live Hl2Backend. So telemetry target 10.0.0.9 while connected to a different radio repoints that shared poller, and the connected session's health then merges radio B's temperatureRaw / forwardPowerRaw / ptt / radioInUse as radio A's rows. Hl2Backend::telemetryLinkState() and healthSnapshot()'s haveStreamFree both read m_telemetryService->lastReply(), which now describes radio B. That is precisely the "frozen reading wearing a different address" failure setTarget()'s own comment says the design exists to prevent.

In the other order, Hl2Backend::connectRadio() unconditionally calls setTelemetryPollTarget(host) (Hl2Backend.cpp:1776), silently discarding an aim the bridge already answered ok to. And telemetry target off disarms the connected session's stall diagnostic.

4. The stated protection for off-subnet unicast does not exist in this build. Inline on AutomationServer.cpp:6919.

The comment justifying the permissive address policy says: "What protects the wrong-unicast case is the reply side … Hl2TelemetryPoller checks the MAC in the answer, so a stranger who replies is discarded rather than believed." setExpectedMac() has no production caller — grep finds only its own definition, Hl2TelemetryService's forwarder, and the two declarations; nothing calls the forwarder. m_expectedMac is always nullopt, so the MAC filter is dead code on this path. The only filters actually applied are sender-address equality and isHermesLite2(), so a mistyped IP that happens to host any HPSDR-speaking device gets its readings believed and rendered as this radio's health.

Either arm the MAC check at the aim, or drop the claim — but the address policy should not rest on a filter that is never armed.

5. The merged snapshot draws ~11 repeated bold section headers in the Radio Health dialog. Inline on RadioHealthDialog.cpp:132.

Hl2TelemetryService::healthRows()'s put() does h.sections.insert(k, "Telemetry source") for every key, while Hl2Backend::healthSnapshot() sets a section only on group-leading keys. RadioHealthDialog::refresh() inserts a bold header row for any key present in snap.sections (RadioHealthDialog.cpp:157). After the merge only telemetrySource and forwardPowerRaw get their section overwritten by the backend; telemetryAgeMs, telemetryUnanswered, telemetryPollMs, temperatureRaw, reversePowerRaw, biasCurrentRaw, txFifoFillMsbs, txFifoRecovery, ptt, radioInUse and pttHangTimeMs each keep their own "Telemetry source" header — a bold header interleaved with nearly every single row. It also breaks the contract docs/automation-bridge.md:3427 states for health: "section appears on the first row of each group and is absent on the rest."

Latent before this PR only because nothing constructed the service.

6. The body says this PR has no operator-facing surface. It does. Inline on RadioHealthDialog.cpp:132.

"Honest gaps" still reads: "No operator-facing surface. RadioHealthDialog still reads backendHealthSnapshot() unmerged … Bridge-only staging, deliberate, and a third change behind its own RFC." Commit ab21f0198 made the dialog do the merge. You said so in the review thread ("a real UI change and now a disclosed one") — but that disclosure lives in a thread reply while the body asserts the opposite and routes the change to "its own RFC".

It is also more than display. On main, nothing calls noteDemand() — zero callers. This PR wires demand, and the dialog's 500 ms refresh calls offlineHealthRows() → noteOfflineDemand() at 2 Hz, which now arms the poller synchronously. Since Hl2Backend::connectRadio() sets the poll target and nothing clears it on disconnect, opening the Radio Health dialog is by itself enough to start 1 Hz UDP probing of the last-known radio in NotConnected/HeldByOther — the states where Hl2TelemetryCadence.h gates on demand precisely because those packets land in somebody else's session. A health read does the same: there is no way to read health without arming the probe.

To be fair on blast radius: all of this is gated on hasOfflineHealth(), so Flex, Icom and Sim are byte-identical — I verified that live. This is HL2-only and defensible on the merits. The body simply needs to say it.

Nits (non-blocking)

• setOfflineHealthTarget(null)'s documented release never fires. RadioModel.h:375 promises "releases the source, so the rows go away again", but releaseOfflineHealthIfUnused() bails whenever m_backend is non-null — and it always is (teardownBackend()'s only callers are ~RadioModel(), setBackendForTest() and rebuildBackendForFamily(); not a plain disconnect). So after telemetry target off the telemetrySource/telemetryAgeMs/telemetryPollMs block stays, which is the defect the function's own comment says it fixed. Your test pins this rather than catching it ('off' does not destroy the source while a backend borrows it). Traffic does stop, so this is contract-vs-code, not safety.
• The premise the design rests on is inaccurate. OfflineHealthSource.h:8 and Hl2TelemetryService.h:11 say m_backend "is constructed inside connectToRadio()". It is constructed in setupBackend(), from the RadioModel constructor and rebuildBackendForFamily(). Verified on the demo: after disconnect, get_state model=radio shows connectState: idle while telemetry still answers family ('sim') — the backend outlived the connection. This matters because "another client holds the radio" is reached via the picker → connectToRadio() → an Hl2Backend is built before the connect is refused, so a capability record is readable in the headline case. That weakens "a capability flag structurally cannot answer it", which is the argument for touching src/models/. The seam may still be the better design — but the ruling should rest on the real trade-off.
• temperatureC is now a dash in exactly the states the feature is for. The offline source publishes temperatureRaw but never temperatureC, so with the backend blanking it the headline question ("what is its PA temperature while somebody else has the stream?") answers — next to a live raw count. Hl2Backend::temperatureCelsius(int) is a static in the same family directory and could convert d->reply->temperatureRaw.
• linkDown clears the PA-temp pole without a meter update. Hl2Backend.cpp:503 sets m_havePaTemp=false, but RAD:PATEMP is emitted only from publishTelemetry() (5845), which no longer runs — so the meter surface keeps showing the pre-drop temperature while the health row for the same register goes blank.
• IPv6 slips the address gate. Verified live: telemetry target :: reaches the family refusal, so it passed validation — the check tests AnyIPv4 and Any, neither of which equals AnyIPv6. (ff02::1 is caught; isMulticast() works.) Any IPv6 unicast is also accepted but unpollable, since the socket binds AnyIPv4; writeDatagram's return is discarded and m_unanswered increments at send time, so health would report a climbing unanswered count for datagrams that structurally cannot leave.
• tools/check_localization.py does not exist in this repo — RadioModel.cpp:832's comment shapes code wording around it. It is your lab-side script (as the body says of the pre-PR grep); that rationale belongs in the PR body, not as standing guidance in src/.
• The ── Backend health snapshot ── banner now sits above doTelemetry(), orphaning doHealth() from its own header comment — and the banner ends "Read-only and TX-safe: it keys nothing and changes nothing", directly above the verb that puts datagrams on the wire.
• The new public verb has no prose docs section. Every comparable verb has one (health at docs/automation-bridge.md:3381); telemetry gets only the generated table row, so a third party has no documentation of the response shape — which differs between the off path and the aim path — the refusal reasons, or that a successful aim starts 1 Hz traffic. The adjacent health section is now stale too.
• declare() silently last-wins though the header calls a double declaration a programming error; a qWarning would surface the link-order-dependent case the LINKAGE note says this design must avoid.
• The source is owned twice — parented to the RadioModel QObject and held in a unique_ptr. Safe today only because members are destroyed before the QObject base unregisters children; a future deleteLater() or a qDeleteAll(children()) turns it into a double free.
• Body says 24 assertions; the binary prints 25. IOfflineHealthSource::hasOfflineTarget() has no caller outside the test. The test omits TestSettingsProfile.h while constructing a real RadioModel — the precedent it mirrors (extension_namespace_gate_test) omits it too and I saw no writes to the real store, so that one is genuinely minor.

What I tried to break, and what held

• Mutation. Forced declaredFor() to return true → 9 checks failed, exactly the 9 the body claims, and your honest caveat held: the Flex refusal survives the mutation because create() returning null is a second gate. Restored, re-verified green.
• The cross-family leak, driven live. Demo simulator (DEMO-0001, family sim), isolated AETHER_SETTINGS_DIR, offscreen, AETHER_AUTOMATION_NO_TX=1. telemetry target 192.0.2.1 refused on flex and sim; telemetry target off refused; health → rows: [] before connect, while connected, and after disconnect. 224.0.0.1 and not-an-ip both correctly refused. The operator's FLEX-8600 was visible in connect list and never touched.
• The release path. Walked every setupBackend() caller looking for one where a stale HL2 source could survive into a Flex session. There isn't one — teardownBackend() nulls m_backend before setupBackend() on every path, and the constructor starts from null. That hypothesis died; the gate is correct.
• hl2MergeHealth. Checked it is genuinely a forwarder to mergeHealthSnapshots() rather than a re-typed twin, so the HL2 tests still pin the shared rule. It is.
• Tests and checkers. offline_health_registry_test 25/25 and hl2_telemetry_service_test green, built at PR head with ninja -j8. gen_touchpoint_manifest.py --check → "manifest up to date".

Not verified: anything needing real HL2 hardware. The entire hl2 column of the body's family table — merged rows, in-band-wins-on-collision, the HeldByOther transition — is reasoned from code, not measured; the demo is family sim and declares no offline source, so it can only exercise the refusal side. Blockers 2–5 and the first three nits are reasoned-from-code with call sites cited; blocker 1 and the IPv6 and backend-lifetime points are reproduced.

Preflight: re-run against the PR's own sources. My initial read cleared it as socket-free; that was wrong, and blocker 1 is the correction, with the operator notified.

[ten9876]

Reviewed at head 1dec6f90, on Linux/GCC 16.2.1, Qt 6.9, RelWithDebInfo, merge base 26998942. This is a re-review after the last round: five of @ten9876's six blockers are fixed and verified (details in "What held up"). The findings below are new, plus the three nits from that round that are still open.

Issue fit

No linked issue and no [RFC], as the body says. Judged against its own stated intent — the "separate, capability-shaped PR" docs/HERMES.md asks for when the seam is missing a verb — the mechanism is right: IOfflineHealthSource + OfflineHealthRegistry give the model a health path not conditional on m_backend, the dynamic_cast<hl2::Hl2Backend*> moves down to Hl2Backend::setOfflineHealthSource(), and no family string is added above the seam. I mutated declaredFor() default-open and got exactly the 9 failures the body claims, with the Flex refusal surviving for the second reason the body states.

Does it solve the problem? Partially. Two of the three questions in the opening section are not reachable as shipped: the verb cannot be aimed until connectToRadio() has run for an HL2 in this process (blocker 5), and the PA-temperature question is answered only in raw counts (nit 3). And the branch does not compile on Linux at all (blocker 1).

Scope

File / group	What it changes	Claimed in the body?	Verdict
backends/OfflineHealthSource.{h,cpp}	seam interface + family→factory registry	yes	in scope
backends/HealthSnapshotMerge.h	merge rule moved out of the HL2 header	yes	in scope — verified a forwarder, not a twin (hl2MergeHealth is 1 line)
IRadioBackend.h	setOfflineHealthSource(), no-op default	yes	in scope
hl2/Hl2TelemetryService.{h,cpp}	registrar, hasOfflineTarget(), section fix, radioInUse gate, leftOurOwnSession	mostly	in scope
hl2/Hl2TelemetryCadence.h	acceptReply() + ReplyAcceptance	yes	in scope — but breaks the build, blocker 1
hl2/Hl2TelemetryPoller.{h,cpp}	MAC latch, checked bind()	yes	in scope
hl2/Hl2Backend.h	seam override + in-family dynamic_cast	yes	in scope
hl2/Hl2Backend.cpp — temperatureC gate, PA-temp pole clear on linkDown	user-visible HL2 health change	no	still undisclosed from the last round; see nit 3
models/RadioModel.{h,cpp}	owns/releases the source, declaration gate, connected-refusal	yes (the two explained grep hits)	in scope
AutomationServer.{h,cpp}	new telemetry verb, address validation, doHealth() merge	yes	new public surface — maintainer call
gui/RadioHealthDialog.cpp	merges offline rows, 2 Hz demand driver	yes (body corrected this round)	in scope
docs/automation-bridge.md, docs/architecture/aetherd-touchpoint*	regenerated verb table + touchpoint manifest	implied	in scope — gen_bridge_docs.py --check and gen_touchpoint_manifest.py --check both pass
CMakeLists.txt, tests/tests.cmake, 3 test files	registration + coverage	yes	in scope

Nothing in the diff is unrelated to the feature: no bundled build workaround, no drive-by reformat, no CHANGELOG.md entry (correct — it is release-prep only). No commit's author date predates the branch. The body's pre-PR-grep claim ("two hits, both src/models/RadioModel.*, zero violations") holds — I grepped added lines in src/models/ and src/core/AutomationServer.cpp for family strings and found none. The one scope gap is disclosure, unchanged from the last round: the Hl2Backend.cpp health-row behaviour changes are still absent from the body.

Test-boundary preflight

This PR adds no socket-owning test and no synthetic peer. offline_health_registry_test, hl2_telemetry_cadence_test and hl2_telemetry_service_test contain no QUdpSocket/QTcpSocket/bind/listen/connectToHost/Fake*. I re-measured the socket-free claim independently of the macOS DYLD run in the body: under an LD_PRELOAD interposer on socket/bind/sendto/sendmsg, offline_health_registry_test makes zero AF_INET calls. The instrument was validated with a positive control — a Qt program making the exact bind(AnyIPv4,0,ShareAddress) + writeDatagram pair from applyCadence() was caught:

[SHIM] socket domain=2 type=526338
[SHIM] bind AF_INET 0.0.0.0:0
[SHIM] sendmsg AF_INET 192.0.2.1:1025

@ten9876's blocker 1 is fixed.

---

Blockers

1 — the branch does not compile on Linux. Hl2TelemetryCadence.h uses std::uint8_t without including <cstdint>. libc++ pulls it in transitively through <array>/<optional>; libstdc++ does not, so check-macos is green and the build job is red. Reproduced locally with a bare g++ -fsyntax-only. This is the newest commit's code, so the body's "Full build — 0 errors" and "Full CTest 439/441" were both measured before it existed and only on the platform where the omission is invisible. CONTRIBUTING.md wants cross-platform. One-line fix, suggestion inline.

2 — a second declaring family is served the FIRST family's instrument. RadioModel::ensureOfflineHealth() builds a source only if (!m_offlineHealth) and never asks whether the one it already holds belongs to m_family; setupBackend() only releases when the new family declares nothing. So a switch between two declaring families keeps the first one's source. This is the exact cross-family attribution leak the PR says it closed — closed only for families that declare nothing — and it directly refutes the body's central claim, "A family that declares an offline source in future gets this verb with no edit in src/models/." Latent today because only hl2 declares. Proven with a probe that declares a second family, then switches:

[ OK ] build the hl2 backend
[ OK ] hl2 session has an offline source
  rows the HL2 session is served: whoAmI
  whoAmI on the HL2 session = "SECOND-FAMILY"
[FAIL] the HL2 session is served by the HL2 source (telemetrySource row present)
[FAIL] and NOT by the other declaring family's source

The new test never covers declaring→declaring, so nothing catches it. Inline on RadioModel.cpp.

3 — the refusal names the wrong reason, which is the one thing the helper exists to prevent. offlineHealthRefusal() tests connected first; RadioModel::setOfflineHealthTarget() refuses on the declaration first and the connection second. On a connected non-declaring family the caller is told to disconnect and retry — the retry that can never work. Its own comment says "a caller that cannot tell them apart will retry the one it cannot fix." Reproduced on a connected demo (sim) session:

connected   → telemetry: this session is connected ... disconnect first, or just read `health`
disconnected→ telemetry: this session's family ('sim') declares no offline health source

Same refusal, same cause, two different stories. Suggestion inline.

4 — a directed subnet broadcast passes the address gate. The check refuses QHostAddress::Broadcast (255.255.255.255), multicast and the unspecified addresses. 192.168.50.255 is none of those, and applyCadence() sets SO_BROADCAST on every socket it binds, so the datagram does leave. Confirmed live — both reach the family gate, which means the address gate passed them:

192.168.50.255 → telemetry: this session's family ('sim') declares no offline health source ...
10.255.255.255 → telemetry: this session's family ('sim') declares no offline health source ...
0.0.0.0        → telemetry target: '0.0.0.0' is a broadcast, multicast or unspecified address ...

On an hl2 session 192.168.50.255 would be accepted, and that is the broadcast address of the segment holding this station's FLEX-8600. The comment above the gate says "Refused: multicast, broadcast and the unspecified address. Each of those reaches hosts nobody named" — a directed broadcast has exactly that property. (Address validation otherwise held up well: ::ffff:224.0.0.1, notanip, 224.0.0.1, 255.255.255.255 and 0.0.0.0 are all correctly refused.)

5 — the verb cannot be aimed in the state it exists for. m_family is set only by connectToRadio() (via rebuildBackendForFamily) and by the two test hooks. On a fresh app it is flex, so the family gate added this round refuses the verb outright:

{"cmd":"telemetry","action":"target","value":"192.0.2.1"}
→ telemetry: this session's family ('flex') declares no offline health source, so there is nothing to aim

To use the verb against a radio another client is holding you must first call connectToRadio() on it — the write-during-someone-else's-session that doTelemetry()'s own comment says is the reason this verb exists. The feature as shipped serves "I connected to this HL2 earlier in this process and then lost it", not "I have never talked to this radio". That is still a useful state, and the gate itself is right, so this may be a maintainer call on shape rather than a code fix — but the body should say which state is actually served.

---

Nits (non-blocking)

1. telemetry target off never releases the source in a real session (still open from the last round). releaseOfflineHealthIfUnused() returns early while m_backend is non-null, and teardownBackend()'s only callers are ~RadioModel(), setBackendForTest() and rebuildBackendForFamily() — a plain disconnect does not reach any of them. So after any HL2 connect the source lives for the process and hasOfflineHealth() stays true; only a family switch releases it. RadioModel.h:375 states the opposite, and the new test asserts the code's behaviour ("'off' does not destroy the source while a backend borrows it") rather than the documented one. The traffic does stop — setTarget(null) clears m_lastResponder, so pollDestination() is null and applyCadence() drops the socket — so this is a claim defect, not a leak.

2. The stated mechanism for the premise is wrong (still open). m_backend is not constructed in connectToRadio(); setupBackend() builds one from the RadioModel constructor. The observable premise does hold — health on a fresh app returns {"connected":false,"ok":true,"rows":[]}, because FlexBackend::healthSnapshot() is empty when not connected — but the sentence a reader will check is inaccurate, and it is load-bearing for the governance argument.

3. temperatureC is blanked with nothing to replace it (still open). The inBandLive gate is correct and consistent with the rows around it, but Hl2TelemetryService::healthRows() publishes temperatureRaw and never a converted temperatureC, while Hl2Backend::temperatureCelsius(int) already exists as a public static in the same family directory. So "what is its PA temperature while somebody else has the stream?" — one of the three questions in the opening section — renders as PA temperature (°C): — next to a raw count. Two lines in healthRows() would answer it.

4. health's prose is now stale and telemetry has none. docs/automation-bridge.md:3381 still opens "The backend's view of the radio" and says an empty rows with ok:true means no radio connected — both now qualified by the merge. The new verb gets only the generated table row: nothing documents the refusals, the address policy, or that reading health arms a 1 Hz UDP probe. For a public verb third parties bind to, that is the part worth writing down.

5. setExpectedMac() is now provably dead (no production caller) and its acceptReply() branch is exercised only by the test. Worth deleting or wiring, not leaving as a third MAC concept.

6. RadioModel.h cites "roadmap #15" in three comments; I could not find it in ROADMAP.md or anywhere under docs/.

7. Governance. No linked issue, no [RFC]. New seam interface, new registry, a new timer, a second UDP socket and a new public bridge verb. GOVERNANCE.md §"What requires an RFC" lists architecture changes (new signal routing) and new feature areas. The body flags this itself and asks for a ruling, which is the right call — it just needs an accurate body first (blockers 2 and 5, nits 1–3).

---

What I tried to break, and what held up

• The last round's five code blockers are genuinely fixed. Each verified by mutation, not by reading: reverting the radioInUse gate fails 2 checks; stamping every row with a section fails the header check (sections: 4 of 4 rows carry one); removing the MAC latch fails 2 cadence checks; declaredFor() default-open fails exactly 9. Every one of the new tests fails when its fix is reverted — none of them pin nothing.
• The socket-free claim now holds, measured independently on Linux/glibc with a validated interposer (above). The bind() return is now checked and the failure path drops the socket rather than counting phantom unanswered polls.
• The cross-family gate works for non-declaring families. Drove a demo (sim) session end to end: telemetry target refused before connect, while connected, and after disconnect, with nothing constructed; health returned rows: [] in every one of those states, so no HL2 attribution rows leak into another family. That is the leak @ten9876 reproduced on #5414 and it is closed.
• hl2MergeHealth is a forwarder, not a twin — one line calling mergeHealthSnapshots, so the HL2 tests still pin the shared rule.
• All four repo checkers pass locally: gen_touchpoint_manifest.py --check, check_test_registration.py, check_ci_test_gate.py, check_engine_boundary.py, plus gen_bridge_docs.py --check.
• With <cstdint> added, 56/56 of the hl2_* / health / telemetry / automation_* targets pass on this box. Blocker 1 is the only thing between this branch and a green Linux build.
• Could not verify: anything requiring real HL2 hardware — the connected-and-stalled and held-by-another-client paths, the merged dialog rendering, and the leftOurOwnSession transition are reasoned from code, not reproduced. The demo simulator declares no offline source, so the merge path is unreachable there; I did not go near the FLEX-8600. Blockers 2 and 5 and nits 1–3 are code-reasoned but each is backed by a run above or by a probe.
• Instance driven: my own offscreen demo instance (pid 127778, socket aethersdr-pr5642, isolated AETHER_SETTINGS_DIR/HOME, AETHER_AUTOMATION_NO_TX=1), attached to DEMO-0001 / "AetherSDR Demo", closed afterwards. Nothing was keyed.

Requesting changes for blocker 1 at minimum — the branch cannot merge red. 2, 3 and 4 are each small and self-contained. 5 and the governance question need your call, @jensenpat.

[ten9876]

Approving at 16161dbe

Every finding from the previous round is fixed and verified, and the branch is
green on all five checks including the Linux build job that was red.

What changed since 1dec6f90

Finding	Fix	How it is pinned
Linux build failure — std::uint8_t with no <cstdint>	include added	CI build now passes; reproduced the failure with g++ -fsyntax-only first
A second declaring family was served the first one's instrument	the source is tagged with the family that built it; ensureOfflineHealth(family) rebuilds on a mismatch	registry test §6; reverting the rebuild fails 4 checks
The verb could not be aimed from a cold start	telemetry target <ip> resolves the address against the discovery table and builds that radio's family's instrument — no connection, no change to m_family	registry test §6; confirmed live from a never-connected session
The refusal named the wrong reason	setOfflineHealthTarget() returns an OfflineAimResult; the message renders the model's verdict instead of re-deriving it	confirmed live on a connected sim session
A directed subnet broadcast passed the address gate	local segment broadcasts enumerated and refused; the remote case named as unidentifiable rather than implied covered	confirmed live: 192.168.50.255 now refused
telemetry target off never let go	releaseOfflineHealth() hands the borrow back through setOfflineHealthSource(nullptr), then destroys	registry test asserts the destructor ran; reverting fails 8 checks
The PA-temperature question went unanswered	conversion moved to MetisProtocol.h beside the decode, shared by both paths; temperatureC published; RAD:PATEMP follows the poller when in-band is down	service test §7; reverting fails 2 checks
Stale prose	premise corrected, telemetry prose written, health prose updated for the merge and the demand signal, setExpectedMac() deleted, bad citation removed	gen_bridge_docs.py --check

One gap the discovery-derived aim opened was found and closed before this
approval: connectToRadio() skips setupBackend() when the family is
unchanged, so aiming at an HL2 and then connecting to an already-selected Flex
would have carried HL2 rows into the Flex session. The session taking the wire
now reclaims the instrument, with coverage.

What I tried to break, and what held

• Every fix mutation-tested rather than eyeballed. Reverting the family
  rebuild, the release, and the degrees row fails 4, 8 and 2 checks
  respectively; the earlier round's fixes still fail 9, 2, 1 and 2 when
  reverted. No test in this branch passes against its own unfixed code.
• Socket-free re-measured on Linux/glibc under an LD_PRELOAD interposer on
  socket/bind/sendto/sendmsg, validated with a Qt positive control that
  catches the exact bind+writeDatagram pair applyCadence() makes: zero
  AF_INET calls, including with the new cold-start coverage.
• Driven against the demo simulator, not hardware: cold-start aim, the
  refusal wording connected and disconnected, every address the gate refuses,
  the idempotent stop. health on sim returned rows: [] in every state, so
  no attribution rows leak into a non-declaring family.
• 111/111 of the hl2/health/telemetry/automation/radio/metis/settings
  targets pass post-merge; all five repo checkers pass.
• connection_panel_size_test fails on this box — and fails identically
  with the pre-fix RadioModel/AutomationServer restored, so it is
  pre-existing and unrelated. It is not in ci.yml's filter.
• Not verified on hardware. The connected-and-stalled and
  held-by-another-client paths, and the merged dialog rendering, are reachable
  by construction rather than by measurement — the demo declares no offline
  source, so the merge path cannot be reached there. No radio was connected and
  nothing was transmitted.

Governance

The body still flags that this lands a new public bridge verb, a new seam
interface, a registry, a timer and a second UDP socket without an RFC.
Approving on the maintainer's explicit instruction to proceed; the ruling is
his, and it is recorded here rather than left implied.