Assertions are sacred

Then steps are sacred. The agent may fix how a run reaches an assertion, never what it checks. This is enforced mechanically, because prompts alone proved insufficient in live testing:

1. Heal merges never take agent-recorded assertion actions; the cached assertion is the contract.
2. When the failed step is an assertion, the orchestrator re-executes the cached assertion as written on the live page after the agent claims success: if it doesn't pass, the run is red, whatever the agent says.
3. An assertion step that recorded no check at all fails on replay instead of passing silently. A Then with an empty action list verified nothing, so a scenario's verdict can never rest on it; the recording is also filed unverified, so accept --all will not take it.
4. A negative assertion (expectNotVisible) must hold for every recorded locator. Taking the first candidate that happened to be hidden would pass while the element is still on screen under a fallback.

Assertion policy (M4). The default policy is "strict": no assertion is ever adapted, period. Projects can opt into "assertionPolicy": "adaptable-mid" (or --assertion-policy adaptable-mid): mid-scenario assertions, checkpoints followed by further actions: may then be adapted by the agent when the UI legitimately changed, always with an explicit adaptation note and a suggested .feature edit, and always subject to the zero-AI proof replay and your accept gate. The final assertion block of a scenario, its verdict, the trailing run of Then/And assertion steps, is strict under every policy, forever: never merged from agent recordings, always re-verified as written by the orchestrator, never refined around.