exp-34 fixture uses non-contract receipt field; regressed by RT-30 attestation

[heybeaux]

Found during independent post-merge verification of exp-40 (2026-09-15 nightly). Filing rather than silently patching, since exp-34/RT-25 is already-landed evidence.

Summary

exp-34-effect-outcome-receipt-binding is currently red against Aegis main, in the two legitimate-completion scenarios:

• valid-verified-receipt → got indeterminate, expected executed
• duplicate-valid-receipt → got indeterminate, expected executed

Metrics: legitimateCompletionBlockRate 0.25, completionAccuracy 0.75, idempotentCompletionSafety 0.

Bisect

• green at aegis d1db8d5 (pre-exp-39)
• red at aegis 6f24d45 (post-exp-39/RT-30, pre-exp-40)
• still red at aegis b50b46d (exp-40 merge)

So this was introduced by the exp-39/RT-30 terminal write attestation change, not by exp-40.

Root cause

exp-34's mock host store persists the terminal receipt on a field named receipt:

type Effect={...;claimed:boolean;receipt?:Receipt}

The documented public contract (ApprovalExecutionEffectRecord, also in dist/index.d.ts) specifies successReceipt / failureReceipt. RT-30 attestation reads back the retained record and cannot see a contract-violating field, so it correctly declines to assert terminal certainty.

Sibling exp-35 already uses successReceipt/failureReceipt and stays green.

Severity

Not a safety defect. All unsafe rates remain 0 (falseExecuted, misboundCommit, unverifiedCommit, indeterminateCommitExecution). Aegis fails closed to indeterminate, which is the safe direction. The stale fixture is wrong, not the runtime.

Verification

Repointing only the exp-34 fixture field receipt → successReceipt makes exp-34 fully green against merged Aegis b50b46d (completionAccuracy 1, idempotentCompletionSafety 1, legitimateCompletionBlockRate 0). That diagnostic edit was reverted; no landed fixture was rewritten.

Suggested follow-up

1. Update the exp-34 fixture to the documented successReceipt contract and re-pin its RT-25 trace.
2. Consider an Aegis-side diagnostic distinguishing "host record violates the documented receipt contract" from a generic receipt_unverified, so contract drift is loud instead of silently fail-closed.