Contact records acceptance
Verification Boundary
The selected contact records acceptance files cross the browser interaction boundary described below.
What This Suite Proves
Creation journeys join the chooser and contact form to an independent API read of the saved person. Correction journeys compare edited values with stored data and retain communication details that the edit does not change. Archive and history journeys inspect the retained record; the deletion journey uses the public API and asserts the absent record and owned information. No control is claimed without an independently mapped refusal case.
What It Does Not Prove
Communication preferences being stored does not establish campaign delivery. Contact form, conflict and computed-name assertions contribute only their named scenario portions. Shared shell accessibility and final photo storage are not certified by a visible card.
Level and Rationale
These assertions join staff actions to the console’s route, form or record presentation and, where present, an independent stored read. A service integration test cannot establish that the person can reach and use those controls. Browser execution supplies the interaction boundary while stronger server cases retain their separate API register.
Lifecycle Coverage
Create and change are exercised for contacts through console forms with stored-value checks. Archive and restoration are exercised through the console and inspected through APIs. Delete is exercised as an explicitly API-only administrator step inside the browser journey; it is not a console delete button. Merge belongs to Data Quality. Reconcile does not apply to this contact-edit boundary; affiliations and compliance have their own reconciliation proof.
Real Dependencies and Test Doubles
The browser, sign-in and development APIs supply record interactions. Journey helpers perform console actions and independent API verification. Selected tests declare controlled outcomes in their own source; a supplied response proves only the matching browser behavior, while fresh service reads establish any stored result claimed by that case.
Must Not Be Doubled
Keep the actual console workflow and every independent API read used as persisted verification. Setup may create related fixtures through the API, but cannot stand in for the customer action claimed as console-driven. A cleanup delete is not lifecycle proof unless the journey independently asserts the deleted stored result.
Fixtures and Isolation
The creation journey owns a run-marked contact type and named contact; shared custom-field definitions stay in place. Relationship fixtures create employers before people and register cleanup as soon as identities exist. Archive and delete cases deliberately retain history to assert the result, then clean up only their own remaining fixtures.
Determinism and Retries
Two-person conflict cases use independent signed-in browser sessions. Stored values, versions and run names are explicit premises. Eventual search results use bounded polling; a stale hit is evidence until the asserted bound expires. The acceptance runner has zero retries, so a second attempt cannot mask a failed first save.
How It Runs
Use the exact command in the frontmatter from the owning repository. The command selects this register’s browser boundary and limits worker count. Acceptance commands use run-marked development fixtures; fixture and controlled projects retain their distinct environments. The register remains not-run because this authoring pass produces no execution report.
Coverage Gaps
There is no applicable lifecycle marked partial or absent at this boundary. Communication preferences being stored does not establish campaign delivery. Contact form, conflict and computed-name assertions contribute only their named scenario portions. Shared shell accessibility and final photo storage are not certified by a visible card. Existing unbound files supply engineering observations; they do not silently implement additional capability or screen scenarios.