Our UR5e dashboard finds an available state inside a failed reply

That is exactly the current mistake. I have saved a failed reply and a successful one from each documented format, with the version beside them.

Keep the unsupported-version case in the test set as well. Otherwise somebody installs another environment later and your explicit two-format parser quietly becomes a guess again.

Hazel Archer's question is worth testing on the actual screen layout. An unavailable current reading and a dated historical reading can coexist, but they need visibly different roles. Don't rely on one tiny word to explain it.

The current draft blanks the live value and says unavailable. Previous valid reading is in details with its observation time. Nothing historical exists after an initial failure.

Leo, include missing fields and unexpected shapes too; a response can look successful enough to tempt the old parser without being valid for either supported format

Isabel, exactly. I would rather open details deliberately than squint at green and wonder which bit of the message I'm meant to believe.

Both format parsers pass the success, failure and malformed cases offline. The prior observation time was being refreshed on failure; that is now fixed in the draft too.

Which installed environment does the launcher use? Passing a test in one terminal is not enough if the classroom shortcut starts another package copy.

And keep those captured examples separate from deliberately malformed cases. The latter are useful tests, not evidence that the controller sent a reply of that shape.

Launcher path is recorded and uses the intended environment. Captures and constructed cases are separate. The installed screen check has not been completed yet.

Could a person unfamiliar with the rewrite try reading it? The developers already know which bit is old.

Yes, that is in the operator review. They will see current success, failure after success and initial failure without me explaining each screen first.

Include recovery after a valid reading returns; unavailable should not become a permanent display state either

Hazel Bell, agreed. The cheap test sequence is useful in both directions. It should also show that returning data carries its own new observation time, not the old one retained for history.

Screen review passed those transitions, and the read-only installed check matched the documented format. Unsupported-version deployment remains blocked by the new explicit check. I am keeping the alternate-format tests with the handover.

Who owns that test set after handover? The next environment change should trigger it without needing Leo to notice another suspiciously happy tile.