Our wrapper turns part of the container into the displayed number without checking the documented request outcome. I've saved the raw failure and a success from each environment before making changes.

Can you replay those saved responses offline through the same wrapper? Seems a cheaper place to compare the interpretations than repeatedly asking the controller for them.

Use the documentation for each loaded SDK to establish which outcome permits extracting a mode. A plausible numeric field is not enough. I would make the supported interface choice explicit, rather than infer it from whatever returned object happens not to raise an exception.

Don't hide the failure with a default mode. A reassuring number becomes somebody else's maintenance decision, even if the developer knows it is only a fallback.

No default mode in the proposed change. A failed or unrecognised answer will have no current mode; diagnostic detail will remain available. I'm writing the expected screen outcomes before changing the parser.

Does that include a successful response with a mode your display doesn't recognise? Success and meaningful mode aren't quite the same check.

And what about a good reading followed by failure? Testing failure from an empty screen might miss the previous number still looking current.

Rebecca's sequence checks the display's state, not only the parser. Keep it alongside the single-response cases and assert which observation is current, rather than merely assert that an error string appears somewhere.

Added both cases. Unknown mode is labelled unsupported, not translated into a familiar value. Good-then-failed currently leaves the earlier number beside the error, so the display needs work as well as extraction.

I'd remove that number from the current-mode position. Keeping history is optional; making a failed observation look current isn't a useful compromise.

Would a separate last-observed line be clear enough for maintenance, with its time? Asking about their use, not prescribing another busy dashboard panel.

Have someone who didn't write the parser read the two states. They can tell you what they think the screen knows before you explain the new labels.

Maintenance wants only the current result in the main label, with previous observations in the diagnostic view. I've changed the design to match that; the good-then-failed replay now clears the main mode.

Record that behaviour in the tests so a later effort to preserve a useful previous reading does not put it back in the current position. Retain the original captures with their environment identities as well.

Has the normal launch been checked with the intended adapter, or are these still offline results from your development environment?

Offline results only. Thanks, Yasmin; I was about to tell the shift the dashboard was fixed when I'd only fixed and tested the response/display path locally.

Then keep normal-launch verification as the remaining task. The captures gave you a useful diagnosis without proving which adapter the installed screen will load.

I've assigned that check with the intended environment and ordinary account recorded. This stays partial until it passes; no claim that the live maintenance screen is restored yet.