Where do the response examples come from? Use the installed contract and identifiable captured examples where available. A strict fake with an invented contract is still capable of agreeing very confidently with the wrong application.

Do you need all the SDK methods? I would keep this to the reporting boundary, with unsupported calls obvious. Building a pretend robot is a much larger task than checking a parser.

Rachel's initial-failure case matters. Default values can look remarkably official once somebody gives them a green label and a timestamp.

Only three read-only calls are used. I have their installed documentation and two captured successful responses. Failure examples will be documented cases with their source stated, not described as captured events.

Who will update those three contracts when the training environment changes, instead of leaving the next instructor a fake that tests last year's setup?

Keep the examples and expected interpretation versioned beside the adapter, with unsupported shapes rejected explicitly. That makes an environment change a visible review rather than a silent expansion of what the fake approves.

Application maintainer owns that record. Strict argument checks now expose a wrong keyword in our caller. The fake still supplies response cases through the same parser the real application uses.

Good. Has a failed response containing a plausible status value been tested? A range check can miss the original problem if the fake's failure data is conveniently impossible.

And don't replace the real parser in the test to make that case easy to assert. The boundary matters more than the number of mock cases on a report.

That case fails correctly at the adapter now. The screen test found a different issue: after rejection it keeps the last good value under the current heading. Caller keyword repaired, display repair still open.

Show the earlier observation as earlier, if it is useful to keep it. Give the current request its own unavailable result and reason, with the observation time separate from the latest attempted read. The user shouldn't need your test log to discover that no fresh answer arrived.

Who reads the export, if there is one? Fixing the label won't help another report if it still consumes the stale value as current.

There is an export. It had the same stale-current confusion. Both now use the adapter result and separate observation time; initial failure, good-then-failed and malformed cases pass in the offline checks.

Can a different instructor tell from the screen which observation is current, without you explaining the repair beside them?

Instructor readback distinguished unavailable current data from the retained earlier observation. Thanks Rachel, the separate times helped. Real-controller confirmation remains due when the bench returns; timing and disconnect coverage are also unfinished.

Keep those unfinished cases beside the results, not beneath a general passed banner. You have found and repaired specific software defects with a bounded substitute, which is useful without making it more than that.