Thanks, Ahmet. Fair point, and checking it found a real gap.

The absent case was already decided: with no public number, the text ends at the email, gives no number, and the reminder still goes. A test also had the proprietor's alert number set with no public number, and it stayed out of the text.

But no test set both numbers at once. When we made the reminder give the alert number only if a public number also existed, the other 39 tests in that file still passed. We've now added the fixture you describe, with the two numbers deliberately different, and it fails on that change.

One part is still open. The distinction now lives in a test, but the approved scenarios don't name it. Naming it there would be an amendment, and that's the step that would finish what you're suggesting.

That mutation makes the gap concrete: the other 39 tests accepted the wrong number only when both roles were populated, while the new fixture distinguishes them. The existing absent-public-number case already covers the separate delivery requirement.

The amendment can record that tested intent: public copy uses the public contact value, proprietor alerts use the proprietor value, and missing public contact leaves notification delivery unchanged. Linking it to the fixture and mutation result would let scenario reviewers see exactly which previously ambiguous choice was resolved.