Design discussion: single AetherSDR instance, two radios — brief from @nigelfenton

[ten9876]

@nigelfenton dropped a thoughtful design brief on multi-radio support in a single AetherSDR instance — opening the discussion here so the team can sound off, the recommendation can be sharpened, and any agreed direction has somewhere to live as a tracking issue.

The full v0.1 brief follows below verbatim. My review notes (suggestions for v0.2) will follow in a separate comment so they're clearly separable from Nigel's text.

---

AetherSDR — One Instance, Two Radios: a brief for the dev group

• Status: v0.1, discussion-starter — not a spec, not a PR, not a commitment.
• Date: 2026-06-06
• From: Nigel — G0JKN (with Claude as foundations-first reading partner)
• Audience: Jeremy [KK7GWY], Pat [jensenpat], CJ [WT2P], Ryan [NF0T], Robbie [rfoust] — share more widely as the team sees fit.
• Companion docs (Windows dev box, available on request):
  • aethersdr-multi-radio-research-v0.1-2026-05-28.md — verified architecture findings, [verified] vs [open] tags.
  • aethersdr-multi-radio-study-notes.md — bottom-up 7-layer syllabus through the codebase.

---

What this is

Jeremy asked in dev chat 2026-05-28 for "a single instance of AetherSDR to be able to connect to multiple radios at the same time." CJ flagged QA surface doubling. The two companion docs above are the deep-read that came out of that thread.

This brief boils them down to one decision the team would need to make first, and the reasoning that arrived at a recommendation.

---

The crux: how does the protocol surface expose a second radio?

Multi-radio is largely tractable except for one design choice that has to be made upfront, because it has knock-on effects on every existing AE-aware client (WSJT-X, JTDX, aether-pad, Stream Deck / Ulanzi plugins, ShackController, RF2K-S driver, ShackLog, third-party TCI bridges). Two camps:

Camp A — multiplex inside one port

Extend TCI (and CAT) to carry a radio identity. e.g. repurpose trx to encode (radio_index, receiver_index), or add a new radio field.

• Pro: one port. AE feels like one cohesive process from the network side.
• Con: every existing TCI/CAT client breaks until updated by its respective maintainer. That's not "let's coordinate a flag day" — that's "lives unmerged in dev chat for two years."
• Con: redesigning a public protocol is a multi-month design-by-committee path. The cost is mostly not writing AE code; it's writing the spec everyone can agree on.

Camp B — namespace by port

Run a second TCI server (and a second rigctld) on a different port. e.g. Radio 1 on :40001 / :4532, Radio 2 on :40011 / :4533. Each server is the existing unchanged single-radio server class, just bound to a different RadioModel*.

• Pro: zero breakage for existing clients. WSJT-X pointed at :4533 thinks it's the only thing in the world. aether-pad on :40001 still works. Plugins still work. The whole TCI ecosystem keeps functioning, untouched.
• Pro: internally, two copies of code that already exists and is already tested. No new protocol surface. No "what does trx mean now" discussions.
• Pro: consistent with the existing data plane. AE already opens one VITA-49 spectrum stream per radio with no protocol multiplexing — control should follow.
• Pro: incremental & opt-in. The second TCI server only exists when the user enables a second radio. Existing single-radio setups are byte-for-byte unchanged.
• Pro: Hamlib has always worked this way for CAT. One rigctld per rig, on a port the user picks. Every CAT-using app already has a "rigctld port" field. There is literally no client-side change needed for CAT — the user types the second port number.
• Con: discovery: how does a client know :40011 exists? Convention + an enumerator call somewhere. Small problem, not a blocking one.
• Con: two server instances inside AE means a small amount of bookkeeping (lifetime, shutdown order, cleanup on disconnect). Real but well-contained.
• Con: UI orchestration in MainWindow grows — "which radio is the active one for which panel" becomes a real concept. (See architecture section.)

Recommendation: Camp B

The argument that closes it: AE's data plane already does "one stream per radio, no multiplexing." Doing the same on the control plane is consistency, not novelty.

---

What the architecture actually demands (the encouraging part)

The 7-layer bottom-up read says the atom is already right:

• RadioModel is not a singleton. Construct as many as you want. The header literally says it's "the central data model for a connected radio" — singular by intent, not by hidden assumption.
• Per-radio capability state (slice caps, max pans, pan bandwidth — 6700 vs. 6300 etc.) already lives on the model, seeded from the radio's model string at connect. Two sessions get correct independent limits automatically.
• Most dialogs/helpers take RadioModel* by pointer. They're already dependency-injected, not reaching for a global. The DI shape is right.
• Panels use composition + Qt signal/slot — they each hold a RadioModel* and connect their slots to its signals. Hand a panel a different RadioModel* and it just works. Zero changes to panel internals.

The walls are concentrated and identifiable:

• MainWindow.h:420 — RadioModel m_radioModel; embedded by value, not a list. This is the single biggest assumption to lift; once it's a QList<RadioModel*> (or keyed map), the cascade is contained.
• MainWindow.cpp:4612 — TciServer is constructed with &m_radioModel. Multi-radio = construct N of them, each with the right model and port.
• Same shape for the CAT side.

There is no global RadioModel::instance(). There is no inheritance refactor to do. The work is MainWindow orchestration + a thin "active radio" UI concept + the two-server lifetime bookkeeping, not a thousand-cuts patch across panels.

---

Honest estimate

Solo focused dev, broken into a PR series:

• Plumbing (RadioModel collection, MainWindow ownership): a couple of weeks.
• UI orchestration ("active radio" concept, tab/split, status chrome): a few weeks.
• TCI/CAT lifetime (two server instances per AE process, clean up on disconnect): a week-ish.
• Settings/persistence (per-radio namespacing of UUID, station, slice positions): a few days.
• QA matrix (every existing TCI integration validated with two radios): as long as a piece of string. Probably weeks.

Order-of-magnitude: 1–3 months for a usable v1, shipped as 6–10 atomic PRs. CJ's "2× QA" concern is real and built into the estimate.

---

What week 1 looks like

Week 1 is not code. It is:

1. Agree this brief (or the next revision of it) with the team.
2. Decide the discovery convention for "client wants to enumerate AE's radios." Probably a small TCI call that returns [{radio_id, label, scu_count, ports}, …]. Small surface; needs design + agreement, not weeks of work.
3. Sketch the AE-side config for "AE knows it should host a second TCI/rigctld for the second radio" (config file or UI flow).

If week 1 lands well, weeks 2–N are well-defined incremental PRs.

---

What this brief deliberately does not do

• Doesn't propose code.
• Doesn't claim multi-radio is "easy" — it's not, especially the QA matrix.
• Doesn't pretend Camp A is impossible — it's just costly enough that the path-of-least-pain (B) wins on engineering grounds.
• Doesn't presume to volunteer anyone's time. The team picks who and when.

---

Open questions for the team

1. Does the consistency argument (data plane already does N-per-radio) feel right as the framing?
2. Is there a TCI design constraint we've missed — something that forces multiplexing — that would push us back to Camp A?
3. Are there other paths (Camp C?) worth thinking about that we haven't seen?
4. If Camp B is the path, who's the natural lead on the discovery-protocol design conversation?

---

— Nigel · G0JKN

Happy to share the underlying research docs and the architecture syllabus we built before writing this. Both are on a Windows dev box and easy to send.

[ten9876]

Review notes — suggestions for v0.2

@nigelfenton — sat with the brief, walked the load-bearing claims against current main, and drafted notes below for what I think would strengthen it most as it iterates toward v0.2. None of this is gated on you doing anything; if anyone else on the team wants to pick up the threads, that's also welcome.

The architecture claims hold up

I verified the three concrete code claims against current main:

Claim	Reality
MainWindow.h:420 — RadioModel m_radioModel; by value	Correct shape; now at line 440 (we merged ~30 PRs this week — line numbers drifted). Embedded-by-value, not a list.
MainWindow.cpp:4612 — TciServer(&m_radioModel, this)	Correct shape; now at line 5011. DI via pointer.
No RadioModel::instance() singleton anywhere	Confirmed — class RadioModel : public QObject with no static accessor.

The substance checks out everywhere I probed. Nigel clearly read the code, not just the headers.

One place the codebase supports your case even better than the brief realized

CatPort is already an array in MainWindow: m_catPorts[i] = new CatPort(&m_radioModel, this) at MainWindow.cpp:4978, indexed by config slot, each constructed with the radio model and a dialect (Rigctld/etc). Multiple CAT instances bound to one radio is already the production pattern. Camp B for TCI is mirroring an existing project pattern, not introducing a new one. That's a stronger argument than the brief makes — worth promoting into the recommendation paragraph if you iterate.

Three things I'd flag for v0.2

1. The unspoken Camp C: spawn two AE processes.

The brief asks the team for other paths but doesn't surface that the project already trivially supports two AE instances each talking to one radio. Jeremy's original ask was "single instance" — which already rules this out by framing — but the framing itself deserves a paragraph. What does single-instance buy us that two processes don't? Plausible answers: shared device-following audio router, unified settings, one tray icon, one menu bar on macOS, shared multi-flex coordination. If none of those are load-bearing, Camp C wins on engineering grounds the same way B beats A. Worth confronting head-on so the team can sanity-check whether the things single-instance buys actually warrant the cost before committing to either A or B.

2. The audio plane is missing from the architecture section.

The brief covers control plane (TCI/CAT) and data plane (VITA-49 spectrum) but the audio plane is the third surface where multi-radio reshapes things. We just consolidated audio sink/rate negotiation in #3306 / #3397 / #3398 — the assumption baked into that work is one AudioEngine with one canonical 24 kHz RX path. Multi-radio means: does each radio own its own AudioEngine? Or does one AudioEngine route from the active radio? The RX speaker can probably only follow one radio at a time (one set of ears), but DAX TX is plausibly per-radio. The Pudu recorder and QSO playback get genuinely awkward when "which radio's audio am I capturing/playing back?" becomes a real question. Not a blocker — but the second axis (next to control plane) where multi-radio reshapes things, and worth a subsection.

3. Promote "active radio" UI design from a Con bullet to a top-level open question.

The brief lists this under Camp B's Cons as "UI orchestration grows." That undersells it. Single-radio AE has one S-meter, one VFO area, one panadapter region, one applet panel state. Multi-radio means either (a) tab/split with explicit "this panel is bound to Radio 1" semantics, (b) duplicate the whole right-side panel and let it follow active selection, or (c) one panel always active + a small "preview strip" for the inactive radio. Each has implications for menu actions ("Receive frequency" → which radio?), keyboard shortcuts, and the multi-flex protocol layer. This is the design call Jeremy has to make first because Camp B's plumbing shape downstream of MainWindow is shaped by it. Promote to a top-level open question alongside #1–#4 in your existing list.

Smaller items worth a sentence each

• Settings persistence — go nested-from-day-1 (Principle V). The brief mentions "per-radio namespacing of UUID, station, slice positions" as "a few days." The cheapest way for that to age is flat Radio1.UUID / Radio2.UUID keys, which then violates Principle V the moment it lands. Right shape: {"Radios": [{"id": "...", "uuid": "...", ...}, ...]} as a nested-JSON root from the first PR. We just paid the Principle V tax migrating Lean Mode and Display settings — let's not re-create it for radios.

• Multi-Flex interaction. The brief assumes the two radios are different physical units. AE also supports Multi-Flex (one AE client sharing a radio with N other clients). "AE is one process talking to two physical radios, each via Multi-Flex with other clients" raises lock arbitration, TX interlock, and slice-ownership questions. Doesn't have to be solved in v0.1; should be explicitly out-of-scope for v1 so it isn't a surprise later.

• QA matrix scoping. "As long as a piece of string" is honest but defensible to tighten: v1 ships with one tested integration (probably WSJT-X) on the second radio, and explicitly documents everything else as untested. Lets the community report integrations one at a time instead of all-or-nothing.

Things you got exactly right (don't second-guess)

• Recommendation of Camp B. For all the reasons stated, plus the CatPort array confirms it's the existing project pattern.
• "No global, no singleton, no inheritance refactor." Accurate. Work is MainWindow orchestration + two-server lifetime + UI concept.
• Discovery as a small problem. Existing clients don't auto-discover; user types a port. Discovery only matters for future multi-radio-aware clients.
• Estimate of 1–3 months / 6–10 PRs. Feels right given current per-PR throughput on adjacent surfaces. Maybe lean toward 3 once the audio plane and "active radio" UI design get costed.
• Tone. Non-prescriptive, credit-sharing, hedged recommendation, explicit about what it doesn't do. Right pitch for a discussion-starter to a small dev group.

TL;DR if v0.2 makes only three additions

1. A two-paragraph Camp C section confronting "why not two processes" head-on.
2. An audio plane subsection in "What the architecture actually demands."
3. Promote "active radio" UI design to a top-level open question.

Happy to sit with the brief during v0.2, pre-review companion docs if you want to circulate them, or — if Jeremy and the team converge on Camp B — start sketching the first plumbing PR (the RadioModel m_radioModel → QList<RadioModel*> move). Up to you and the team.

73, KK7GWY

[aethersdr-agent]

Triage notes

Labelled maintainer-review + New Feature + protocol + GUI. This isn't a bug to fix — it's a design conversation the dev group has to converge on before any implementation work makes sense. Parking it in maintainer-review so it stays on the team's radar without being picked up for autonomous implementation.

Independent verification of the code claims

I walked the same three load-bearing claims against current main. Same conclusions @ten9876 reached above; line drift only:

• src/gui/MainWindow.h:440 — RadioModel m_radioModel; embedded by value. (Brief said :420.)
• src/gui/MainWindow.cpp:5011 — m_tciServer = new TciServer(&m_radioModel, this);. (Brief said :4612.)
• src/models/RadioModel.h declares class RadioModel : public QObject — no static accessor, no singleton. The header comment explicitly calls it "the central data model for a connected radio" — singular by intent, not by hidden assumption, as the brief said.
• src/core/TciServer.h:48 — explicit TciServer(RadioModel* model, QObject* parent = nullptr);. DI by pointer.

One small structural observation worth folding in

RadioModel owns its sub-models by value — MeterModel m_meterModel; TunerModel m_tunerModel; TransmitModel m_transmitModel; EqualizerModel m_equalizerModel; TnfModel m_tnfModel; SpotModel m_spotModel; CwxModel m_cwxModel; DvkModel m_dvkModel; NavtexModel m_navtexModel; UsbCableModel m_usbCableModel; DaxIqModel m_daxIqModel; FlexWaveformModel m_flexWaveformModel; are all composed into the model, plus RadioConnection* and PanadapterStream* are heap-owned by the model. Lifting RadioModel m_radioModel; → QList<RadioModel*> automatically lifts every one of those sub-models by composition. No separate "now also make MeterModel multi-radio" work item. Reinforces the brief's "the atom is already right" framing — worth a line in v0.2.

The corollary (a small cost, not a blocker): TciServer and CatPort both take RadioModel* at construction with no setRadioModel(...) setter. So a "switch which radio the panel is bound to" UI affordance is a panel-rewiring concern, not a server-rebinding one — servers stay pinned to their radio for life. That's a feature, not a bug (it matches the brief's "each server is the existing unchanged single-radio server class, just bound to a different RadioModel*"), but worth being explicit about because it constrains the "active radio" UI design @ten9876 raised in his note #3 — the panel side moves; the server side doesn't.

Tiny cosmetic note on the brief body

Two template-variable artifacts bled through into the rendered text: **Pro:** **incremental ${ISSUE_BODY} opt-in.** and TciServer is constructed with ${ISSUE_BODY}m_radioModel. Looks like whatever tool authored the issue body did one templating pass too many. Nothing semantic — just a copy-edit for v0.2.

Triage state — why maintainer-review and not something more actionable

This is a discussion-starter, explicitly not a PR or commitment. The decisions in flight (Camp A vs B, audio-plane shape, active-radio UI semantics, Camp C "why not two processes") are all for @ten9876 + the team to converge on, not for me to autonomously pick. Once the team lands on a direction and the maintainer wants plumbing started, dropping aetherclaude-eligible on a scoped PR-shaped follow-up issue (e.g. "lift RadioModel m_radioModel; to a QList<RadioModel*> with the active radio routed through the existing wiring") is the right shape for an autonomous first step.

73, AetherClaude

---

_{🤖 aethersdr-agent · cost: $6.7621 · model: claude-opus-4-7}

[nigelfenton]

Follow-up notes — manageability framing, "Camp B-zero" intermediate step, and a throughput-vs-UX scaling argument

Thanks @ten9876 for the careful read and the v0.2 suggestions — and to @aethersdr-agent for the independent verification and the sub-model-composition find. Both add real value to the brief and I'll fold them into v0.2 verbatim.

A short follow-up conversation surfaced three things I think are worth adding to the discussion before v0.2 lands, because they sharpen the central question ("why single-instance vs N processes?") that the brief deliberately under-articulated.

1. Agreeing with @ten9876's v0.2 suggestions, with one promotion

All three of Jeremy's suggestions land for me:

• Camp C framing (two processes — confronted head-on) — yes, the brief leaves this implicit and it shouldn't. Detail below.
• Audio plane subsection — fair miss on my part. Control + data + audio is the right three-axis framing for any multi-radio architecture. Audio engine assumptions from Consolidate audio sink sample-rate negotiation into one shared component #3306/feat(audio): consolidated sink/rate negotiation foundation (#3306) #3397/feat(audio): live wrapper + RX & TX-mic migration onto the sink factory (#3306) #3398 are exactly the kind of thing that shapes the design.
• "Active radio" UI design promoted to top-level open question — agreed. The downstream plumbing shape is determined by this choice, not the other way round.

The CatPort array find is the single strongest argument I've heard for Camp B. Camp B for TCI is mirroring an existing in-project pattern, not introducing a new one. That deserves to be in the recommendation paragraph itself, not buried mid-section.

Likewise the sub-model composition observation from @aethersdr-agent — RadioModel m_radioModel; → QList<RadioModel*> automatically lifts every MeterModel, TunerModel, TransmitModel, etc. by composition. Reinforces "the atom is already right" in a concrete way the brief should make plain.

2. The Camp C section — where containers fit, and what they don't fix

Camp C deserves a more thorough treatment than "spawn two AE processes." A reader asked the obvious follow-up: what about containers? I think the honest answer reframes the whole single-instance value question.

Containers solve the bare-metal pain points cleanly:

• TCI/CAT port collisions → each container is its own network namespace
• Same GUIClientID UUID in shared settings → each container has its own filesystem
• Same station name from QSysInfo::machineHostName() → each container is its own host
• "Same client reconnecting" eviction war on the Flex → solved as a side-effect

Containers do not solve the user-facing complexity:

Concern	Container reality
Docker install on Windows	WSL2 enabled, virtualization in BIOS, Docker Desktop install. Real friction for typical hams.
USB passthrough for HID controllers (aether-pad, Stream Deck, dials)	Windows: usbipd-win. Mac (native): doesn't really exist for Apple Silicon Docker. This is a hard blocker for Mac users wanting any HID surface in a containerized AE.
Audio in/out of containers	PulseAudio/PipeWire bridge config per OS
Multicast discovery on :4992	--network host (kills port isolation, defeats purpose) OR multicast relay setup OR hardcode the Flex IP
Updating two containers	Two docker pulls + restart per release
Cross-OS coverage	Linux containers + WSLg on Windows or XQuartz on Mac, plus per-OS quirks

The realistic picture: even with project-shipped container images (ghcr.io/aethersdr/aethersdr:latest) and a docker-compose.yml that bakes in the flags, the user is still doing a sysadmin project per shack PC, per OS, per fresh install. For the handful of users who can do that cleanly, fine. For the rest of the user base, it's an effective feature paywall, even when the bits are free.

That's the real selling point of Camp B as I now see it:

Camp B costs the project months of dev work so that it costs the operator one click. Camp C with containers costs each operator a sysadmin afternoon per install, in perpetuity, on every OS the project supports.

Worth surfacing that tradeoff explicitly in the Camp C section of v0.2. It's the strongest single answer to "what does single-instance buy us".

3. "Camp B-zero" — a small intermediate PR series that helps everyone

Stripping containers out and looking at the bare-metal collision points, there are exactly four:

1. TCI port :40001 — hardcoded; no CLI override
2. rigctld port :4532 — hardcoded; CatPort already takes a port at construction, just not exposed
3. Settings directory — single path per user; would carry the per-instance GUIClientID UUID + state if it were configurable
4. Station name — defaults to QSysInfo::machineHostName(); identical for two AEs on one host

Four CLI flags (--tci-port, --rigctld-port, --settings-dir, --station-name) would unblock clean bare-metal multi-AE on every supported OS, with no containers, no Docker, no WSL2, no audio bridge, no multicast relay. Each flag is a small atomic PR — maybe 4–5 in total, with one more to handle DAX endpoint naming.

This isn't Camp B and it doesn't compete with Camp B. Call it "Camp B-zero" — minimum viable multi-AE. It enables:

• The actual bare-metal Camp C the brief asks us to evaluate (so the team can A/B-test "is unified UI worth it?" empirically).
• Containerized Camp C if anyone wants to go that route (the flags compose cleanly with docker run).
• tci-probe and other test rigs that need an isolated AE on a non-default port.
• Dev workflows where a "scratch" AE next to a daily-driver is genuinely useful.

If the team converges on Camp B as the eventual answer, Camp B-zero ships in weeks, not months — and gives Jeremy something concrete to point at when the team is asking "how do we know unified UI is the right amount of work?" The answer becomes: "try the bare-metal version with the flags; report whether bouncing between windows is acceptable."

4. The scaling question that sharpens Camp B's case

A follow-up question: if a shack grows to 4 radios — or 8 — does the Camp B argument get stronger?

Looking at the throughput numbers (back-of-envelope; happy to be corrected):

• VITA-49 spectrum stream from one Flex 6700 at full chat: ~150–200 Mbps
• 1 Gbps LAN comfortably hosts 5–6 Flexes at peak panadapter widths, 8–10 at narrower
• Modern 6-core desktop CPU: ~8–12% per radio at typical settings (extrapolating from Pi 5's measured 23.7% on one Flex 6700). So 6–8 radios CPU-feasible on a normal desktop.
• 8-core / 12-core workstation: 8–15 radios within reach.

So the hardware ceiling for "one PC, many radios" is well above the practical needs of any club, contest super-station, or single shack. The throughput says we can support 6–8. The UX says Camp C breaks down at N=3–4.

The Camp B argument then isn't "is two-radio UX worth months of dev?" — it's "is the architecture that scales gracefully to the 4-radio shack that's hardware-trivial today but operationally impossible without it worth months of dev?"

Worded that way, the question kind of answers itself for clubs and contest stations. And the case strengthens monotonically with N: at N=2 Camp B is a nice-to-have; at N=4 it's the only viable single-operator option; at N=6 it's an empirical necessity.

That scaling argument might warrant its own subsection in v0.2 — "why this matters for >2 radios" — because it's the thing that turns the brief from a 2-radio-UX paper into a multi-radio-shack architecture paper.

Small correction

@aethersdr-agent flagged two ${ISSUE_BODY} template artifacts in the brief body (in the "Pro: incremental ${ISSUE_BODY} opt-in" line and the "TciServer is constructed with ${ISSUE_BODY}m_radioModel" line). Reading the rendered issue body, those artifacts don't appear to be there — the text reads "incremental & opt-in" and "&m_radioModel" respectively, both clean. May have been a parsing artifact at @aethersdr-agent's end; no v0.2 action needed.

What I'll fold into v0.2

If the team's reaction is broadly in line with what I'm reading here — and waiting to hear from @jensenpat, @chibondking, @NF0T, @rfoust — v0.2 would add:

1. The scaling-with-N argument up front (Camp B is for the 4-radio shack, not the 2-radio one).
2. The manageability framing as the explicit answer to "what does single-instance buy us?"
3. The CatPort-array existing-pattern observation promoted into Camp B's recommendation paragraph.
4. The audio plane subsection in architecture.
5. "Active radio" UI as a top-level open question.
6. A Camp C subsection covering containers honestly: what they solve, what they don't, and the user-facing reality.
7. A "Camp B-zero" intermediate-step subsection — the four CLI flags as a small PR series that enables empirical evaluation without preempting the bigger work.
8. Settings persistence: nested-from-day-1 (Principle V) as @ten9876 noted.
9. Multi-Flex coordination: explicitly out-of-scope for v1.
10. QA matrix: tighten to "v1 ships with one tested integration, others documented untested."

Happy to circulate v0.2 in a few days once the broader team has had a chance to chime in. Genuinely grateful for the engagement — this is exactly the discussion the brief was hoping to start.

73, Nigel — G0JKN

[nigelfenton]

A concrete tool behind the QA-matrix answer

One update relevant to CJ's QA-surface-doubling concern. Since the brief was written, I've stood up a working behavioural test harness for AE's TCI surface (tci-probe — Node-RED based, currently in my private incubator repo). Status as of this week:

• Text and binary TCI round-trips proven against a live AE + Flex 6700, including audio-frame header decode (it independently confirmed the TCI Audio on Win11Pro still not working. #3366 format findings from a wire capture).
• Scenarios are packaged data (flow + manifest) with pass/fail verdicts, runnable headlessly via a REST API — first scenario (format3-baseline) passing end-to-end.
• Scenarios take their target endpoint as a run parameter, so under Camp B the same suite runs against radio 1 and radio 2 unchanged — the QA matrix becomes "run the suite twice," not "hand-test everything twice."

It's early — one live scenario, small library, growth model is capturing diagnostic sessions into regression scenarios. But the mechanism exists and round-trips today. Happy to demo it or extract it somewhere visible if it's useful to the discussion; I'll fold the methodology into v0.2 of the brief either way.

73, Nigel — G0JKN
(test-harness design partnership with Claude — Fable)