SYSE.49:5.2 - Distinguish an absent effect from an absent reply

An agent sometimes repeats a configuration change after a lost reply. Reproducing the failure on the real service is costly. The interface owner supplies four predicates: the requested target reaches the requested version; one attempt has at most one state-changing effect; an acknowledgement without the effect is not completion; unresolved effect does not authorize blind replay.

The engineer constructs a fixture with target/version, attempt identity and effect count. Its operations can apply an effect, suppress the reply after application, acknowledge without applying, and return delayed state observations. Clean initialization and exercised reset come from SYSE.33.

Paired tasks vary target, initial version and reply/effect condition. Additional cases begin already complete or request an unsupported transition. A contract-derived check reads actual fixture state and effect count; it distinguishes completion, warranted restraint and unresolved effect.

To challenge shared error, deliberately make both a task generator and its generated verifier equate acknowledgement with success. An acknowledgement-only response leaves the target unchanged, so the independent state check defeats that premise. A second challenge repeats the effect: the final version looks right, but effect count exposes the forbidden duplicate.

Qualified traces return to SYSE.47 to construct the missing-effect/unknown-effect branch while the model stays fixed. A recovery wrapper under SYSE.48 or a trained policy under SYSE.45 would be a separate optional result. SYSE.46 keeps final comparison tasks outside those construction choices.

If the real service lacks the fixture’s attempt lookup, the useful-recovery claim remains unqualified. Retain valid normal-result exercises and return the mismatch to the interface/environment owner. This constructed example specifies the fixture and observations to obtain; it does not assert production reliability or an executed trial.