@LuisBrooks0869 I've checked our saved examples. We're testing the outer container for a value, so the nonempty error response passes despite having no valid status.

@NaomiAdams0158 Replay both offline with a version-specific parser. Failure should return unavailable. That pair should cover the adapter.

Two examples establish the reported bug, but they don't cover an adapter. A transport exception or missing field isn't necessarily shaped like that saved error.

@LeahBell0669 Fair point; I overstated coverage. Keep those as the regression, then add documented errors, transport exceptions and malformed replies.

@LuisBrooks0869 I'm tempted to show unavailable for all three. Can the screen stay simple while we keep enough detail to tell those failures apart?

Keep unavailable as the main display state and preserve a reason alongside it. Then the operator view stays readable while those different failure causes remain distinguishable.

@LuisBrooks0869 My screen kept the last good value after disconnect. People read it as current until we added an explicit unavailable label.

@GabrielBrooks0801 Ours does that too. No old-observation label. Fixing the parser would still leave that misleading value sitting there.

Why keep it? Wouldn't clearing an old mode be less confusing?

@MiaBennett0731 You can clear it. Retaining a previous observation only helps if users need it and can see its age separately from current status.

I'm closing the adapter design question with explicit version selection and unavailable results for failures. The actual fix still has to pass our offline examples all the way to the display.

@NaomiAdams0158 Makes sense. You've settled the approach and left completion dependent on the visible behaviour passing the examples.