The wrapper currently uses a truth test on each response before reading a value. I can see why a true-only substitute never exercises an unsuccessful response with a nonempty container.

Then the substitute should preserve that distinction: transport or method status is not the controller value merely because both arrive together.

Jack, agreed, though don't make the substitute decide the display policy. Feed the failure through the real reporting code and assert what its screen model produces

And include an unsupported method or argument shape, so an interface mistake fails loudly instead of receiving another reassuring true.

Caleb, our application maintainer will own the examples with the wrapper. Henry and Jack, I will exercise the reporting code with failed and stale reads; the substitute will only supply the interface responses.

That's the separation I meant. Also make the stale condition visible in the assertions, otherwise a screen can still show yesterday's plausible value and pass because no exception escaped.

What response evidence have you got, Mei? Documentation and captured replies from your version beat invented structures that happen to suit the current parser

Version-matched documentation and a few retained successful replies. No captured timeout response. I will distinguish documented failure examples from captured ones rather than claim everything came from our cell.

That is enough to begin a bounded software test, provided uncertain interface behaviour stays marked for later controller verification rather than silently becoming the contract.

Keep those unverified cases beside the test results for commissioning handover.

Would a replay of one good read followed by a failure cover the stale display case? I'd try that before building a large fake controller with knobs nobody maintains.

It covers that transition, Jack, not all stale-data behaviour. Add a delayed result after a newer read if the reporter allows overlap; otherwise don't invent concurrency it hasn't got

Our reporter serialises reads, so I have not added overlapping responses. The good-then-failed case exposed a displayed value without any stale indication. That is a screen defect we can fix offline.

Good find. What will the user see while the next read is pending? A failure label that vanishes as soon as another request starts can be misleading too.

The revised screen keeps the last value visibly stale during the next attempt and clears that marking only on a valid fresh read. That sequence passes in the offline test now.

Does handover still identify the timeout behaviour as unverified on the controller?

Yes. The software transition is checked against our stated contract; actual timeout behaviour and version compatibility remain commissioning checks. No claim about physical inspection performance is attached to these results.