Observation
In the PFSM UTM Simulation, with fake_solve_active: false (Synthetic Solve correctly off) and "Solve Simulation (PiFinder built-in): ON" showing green in the Control Center, /api/status on PiFinder itself shows:
solve_source: "CAM"
solve_time / last_solve_success: 1789142606.43 (48+ minutes stale at time of check)
solution.RA/Dec: 297.37° / 8.80° (exactly the last manually-injected fake-solve value, not a fresh solve)
The Control Center's "Solve" status dot/badge (applySolveStatus(), status_page.html) is green and reads "solving (simulated image)" purely because the last KNOWN solve_source was "CAM" - it does not check last_solve_success's age at all, so it cannot distinguish "actively solving right now" from "the last solve was a long time ago and nothing has happened since."
Why this matters
This directly misled a live UAT session (TC-PFSM-FIRSTSTART-01, #374): the badge looked healthy/active while PiFinder was in fact not producing any fresh position data at all. The user's own standing principle here: don't treat a "feature is configured on" flag as equivalent to "is actually, currently working" - see PIFINDER_HORIZON_STATUS/MOUNT_HORIZON_STATUS's existing "not published until a first fresh reading exists" convention, and the no-solve banner's own staleness debounce (_noSolveHasNothing) - a similar staleness gate seems to be missing specifically from this "Solve" status dot.
Suggested direction
Apply the same kind of staleness check the no-solve banner (renderNoSolveBanner()) already does to applySolveStatus()'s dot color/text - e.g. yellow/stale wording once last_solve_success is older than the driver's own SOLVE_FRESHNESS.MAX_AGE_SEC (or a similarly reasoned threshold), not just whichever solve_source value was last seen.
Context
Found during TC-PFSM-FIRSTSTART-01 UAT, see #374 and [Test Execution #382].
Observation
In the PFSM UTM Simulation, with
fake_solve_active: false(Synthetic Solve correctly off) and "Solve Simulation (PiFinder built-in): ON" showing green in the Control Center,/api/statuson PiFinder itself shows:The Control Center's "Solve" status dot/badge (
applySolveStatus(), status_page.html) is green and reads "solving (simulated image)" purely because the last KNOWNsolve_sourcewas "CAM" - it does not checklast_solve_success's age at all, so it cannot distinguish "actively solving right now" from "the last solve was a long time ago and nothing has happened since."Why this matters
This directly misled a live UAT session (TC-PFSM-FIRSTSTART-01, #374): the badge looked healthy/active while PiFinder was in fact not producing any fresh position data at all. The user's own standing principle here: don't treat a "feature is configured on" flag as equivalent to "is actually, currently working" - see PIFINDER_HORIZON_STATUS/MOUNT_HORIZON_STATUS's existing "not published until a first fresh reading exists" convention, and the no-solve banner's own staleness debounce (
_noSolveHasNothing) - a similar staleness gate seems to be missing specifically from this "Solve" status dot.Suggested direction
Apply the same kind of staleness check the no-solve banner (
renderNoSolveBanner()) already does toapplySolveStatus()'s dot color/text - e.g. yellow/stale wording oncelast_solve_successis older than the driver's ownSOLVE_FRESHNESS.MAX_AGE_SEC(or a similarly reasoned threshold), not just whicheversolve_sourcevalue was last seen.Context
Found during TC-PFSM-FIRSTSTART-01 UAT, see #374 and [Test Execution #382].