Edit Contact: Screen Acceptance

What the Suite Proves

These scenarios describe browser checks for a coordinator correcting a contact: review and submission, conflict recovery, validation, protected navigation, permission refusal, source-controlled addresses and primary relationships. Their proof references connect them to the screen criteria and capability rules. Source inspection finds overlapping assertions in the contact records suite, but does not establish full execution coverage of the three previously bound scenarios. All eight scenarios therefore remain proposed here.

Coverage

The first scenario addresses the save criterion; the second addresses conflict recovery. The third covers validation and name handling together, including a disabled-Save expectation that differs from the built button. The fourth addresses Cancel and guarded navigation.

The fifth covers the update permission at editor entry and the API boundary, while the eighth adds loaded and missing-contact states. The sixth checks the Address Editor and linked-removal criterion, which the current implementation does not satisfy on its row source path. The seventh checks the primary-affiliation question. Accessibility has no scenario. The protected coverage map records scenario presence; it is not a report of passing runs or complete executable bindings.

What It Does Not Prove

These proposed browser checks do not replace the capability test specifications' service-level proof, the Contact Records feature suite's complete business process, or the Address Editor's unit criteria. They do not establish accessibility conformance or deployment qualification. The contact journeys provide useful partial evidence, but their existing assertions alone cannot certify every step and expected result written in this screen specification.