CRM configuration acceptance
Verification Boundary
The selected crm configuration acceptance files cross the browser interaction boundary described below.
What This Suite Proves
Catalogue journeys exercise configuration forms, saved ordering, inactive display, type mappings and CRM defaults. The registered feature binding establishes the saved default affiliation choice and its use. Only assertions attached to actual journeys count as product proof; an unbound catalogue file supplies no new scenario binding. No control is claimed without an independently mapped refusal case.
What It Does Not Prove
A type selected by a form does not prove every permission or delete race for that catalogue. Configuration manager behavior belongs to Platform’s reusable shell. Compliance rules on an organization type do not prove final compliance notification delivery.
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 catalogue records through console configuration and stored reads. Archive does not apply to these catalogues: inactive status is a change. Delete is partial because referenced-record refusals and selected catalogue deletions do not establish every catalogue and CRM-settings deletion path. Merge belongs to Data Quality. Reconcile does not apply to catalogue CRUD; using a type can trigger downstream compliance work registered elsewhere.
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 group creates run-marked catalogue identities and temporarily changes shared defaults or order only under exclusive isolation. Mappings name concrete address and phone types, so teardown removes references before definitions. Shared fixture settings are restored rather than left as another run’s baseline.
Determinism and Retries
Order assertions use exact saved positions, and inactive-type assertions distinguish retained selection from offerable choices. Clipboard checks establish only the browser outcome they inspect. The acceptance runner has zero retries; restore failures must remain visible rather than silently resetting a catalogue on another attempt.
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
The lifecycle findings linked above identify every applicable partial or absent lifecycle in this register. A type selected by a form does not prove every permission or delete race for that catalogue. Configuration manager behavior belongs to Platform’s reusable shell. Compliance rules on an organization type do not prove final compliance notification delivery. Existing unbound files supply engineering observations; they do not silently implement additional capability or screen scenarios.