SliceRecreatePolicy: `restoredPanCenterMhz <= 0` fallback is unreachable in production

[ten9876]

Summary

Identified by AetherClaude during review of #3316 (merged), confirmed non-blocking by @rfoust. Filing as a small follow-up.

SliceRecreatePolicy::decide() has a fallback path for "the radio has not reported a pan center yet" gated on restoredPanCenterMhz <= 0. The fallback is dead code in production:

PanadapterModel::m_centerMhz is default-initialized to 14.1, not 0. So when the pan has been claimed but applyPanStatus(center=…) hasn't run yet, restored->centerMhz() returns 14.1 — the policy's > 0 check sees a positive value and skips the fallback entirely.

The two tests covering that branch — testRestoredPanCenterNotYetKnownFallsBackToLastFreq and testRestoredPanCenterUnknownNoSettingsFallsBackToDefault — feed restoredPanCenterMhz = 0.0, a state the production code can't actually reach. The comment in SliceRecreatePolicy.h ("<= 0 means the radio has not reported a center yet (pan only just claimed)") and the matching tests overstate the guarantee.

In practice this is harmless — in the #3212 trace the pan center was populated 1.8s before slice-list returned, and even if it weren't, 14.1 MHz is inside 20m which is a common-enough restore target — but it's a real precision gap between the docs/tests and the production state machine.

Two options, either is fine

Option 1 — make the fallback actually live (more defensive)

Add a bool m_centerReported{false} flag to PanadapterModel, flip it to true in applyPanStatus whenever kvs.contains("center"), expose bool centerReported() const. Have SliceRecreatePolicy::Inputs gate on restoredPanCenterReported instead of restoredPanCenterMhz > 0. Production code can then actually hit the fallback when a pan is claimed but the radio hasn't sent its first display pan ... center= yet.

Option 2 — tighten the comments + drop the unreachable tests

Update SliceRecreatePolicy.h to reflect that pan-center is essentially always used on the reuse path (the <= 0 branch only catches a theoretical zero-init that PanadapterModel doesn't produce). Drop the two unreachable tests. Minimal-change option.

Context

• Original PR: fix(multi-pan): reuse restored pan when slice list is empty on reconnect (#3212) #3316 (merged)
• Source of observation: AetherClaude bot review on fix(multi-pan): reuse restored pan when slice list is empty on reconnect (#3212) #3316
• Triaged as non-blocking by: @rfoust

Tagging @jensenpat as PR author in case he wants to pick this up — it's a 10-30-minute cleanup PR depending on which option you choose. Happy for anyone else to grab it too.

Principle IX (Surface Only What Survives).

[aethersdr-agent]

Triage

Confirmed against current main. The reporter's analysis is accurate end-to-end:

Default init. src/models/PanadapterModel.h:90 — double m_centerMhz{14.1}. Default-constructed, never zero.

Call site. src/models/RadioModel.cpp:4944-4950:

PanadapterModel* restored = (!m_activePanId.isEmpty())
    ? m_panadapters.value(m_activePanId, nullptr)
    : nullptr;
if (restored) {
    in.hasRestoredPan = true;
    in.restoredPanCenterMhz = restored->centerMhz();   // always >= 14.1
}

There is no other production path that constructs Inputs with hasRestoredPan = true and restoredPanCenterMhz = 0.0. So the <= 0 branch in SliceRecreatePolicy.h:78-82 is unreachable from production.

Docs vs. reality. The comment at SliceRecreatePolicy.h:38-39 ("<= 0 means the radio has not reported a center yet (pan only just claimed)") is wrong as stated — a freshly-claimed PanadapterModel reports 14.1, not 0, so the policy treats "not yet reported" as if the radio had said "you're on 14.1 MHz." Harmless in the #3212 scenario (14.1 is a plausible default and well within 20m), but the precision gap is real.

Tests. tests/slice_recreate_policy_test.cpp — testRestoredPanCenterNotYetKnownFallsBackToLastFreq and testRestoredPanCenterUnknownNoSettingsFallsBackToDefault both feed restoredPanCenterMhz = 0.0, which is a state production can't reach.

Handoff — maintainer decision needed

The reporter laid out two options; I have no strong preference because the practical impact is essentially nil. Quick read on each:

• Option 1 (add m_centerReported flag): ~30 min. Touches PanadapterModel.{h,cpp}, SliceRecreatePolicy.h (rename field to restoredPanCenterReported), RadioModel.cpp:4949, and the two tests. Makes the fallback actually live, which means in the (rare) case where the slice-list query resolves before any display pan ... center= status arrives for the claimed pan, we'd land on LastFrequency rather than 14.1. Per the Additional PAN added to session after ASDR and Radio startup. Pulling strange sessions, upon station startup. #3212 trace, that ordering window doesn't naturally occur, so this is defensive-only.

• Option 2 (tighten comments + drop the two tests): ~10 min. Update the Inputs::restoredPanCenterMhz comment in SliceRecreatePolicy.h to note the field is always populated on the reuse path (the <= 0 branch is a paranoia fallback against a zero-init PanadapterModel that doesn't exist), delete the two unreachable tests. Could also collapse the if/else if/else in decide() to just d.freqMhz = in.restoredPanCenterMhz, though keeping the paranoia branch is also fine.

My lean is Option 2 for Principle IX (Surface Only What Survives) — the unreachable branch and matching tests imply a guarantee the production state machine doesn't provide, and the simpler diff doesn't add a flag that exists only to make a defensive fallback testable. But Option 1 is reasonable if you think the slice-list / pan-center ordering could realistically invert in some firmware version or reconnect timing we haven't seen.

Tagging @jensenpat per the original report, @rfoust to pick the option.

---

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

---

_{📍 Citation health check (Foundry Constitution Principle I): 2 resolved, 3 unresolved against /Users/aetherclaude/workspace/AetherSDR at origin/main.}

Unresolved citations (3)

Citation	Reason
RadioModel.cpp:4949	file not found in workspace
SliceRecreatePolicy.h:38-39	file not found in workspace
SliceRecreatePolicy.h:78-82	file not found in workspace