CRM merging browser acceptance
Verification Boundary
A production console build, dev CRM APIs, persona accounts and run-owned seeded records are real. Catalog-blocked journeys and tier-limited steps do not establish full proof.
What This Suite Proves
Scored suggestions, review decisions, merge choices and survivor navigation are checked through a browser and independently read through CRM APIs. The scenario bindings identify the assertions inspected in this examination. No control claim is assigned without a check that fails when the control is removed.
What It Does Not Prove
Eight registered files contain blocked placeholders rather than product assertions. Other journeys can be restricted to an API tier or require destructive opt-in. The file inventory preserves these source boundaries without assigning proof to skipped steps; the blocked files are listed in frontmatter.
Level and Rationale
A browser is needed to check the visible controls, navigation and adapter requests. Lower-level service checks cannot establish those screen outcomes.
Lifecycle Coverage
Create, change and cleanup receive partial credit because these tests select data-quality behavior rather than the complete ordinary record lifecycle. Merge receives partial credit where it appears: a test selection does not establish every contact, organization and external participant variant. Archive belongs to the ordinary record module; deployed reconciliation remains outside these browser and local API selections. The lifecycle finding records these limits.
Real Dependencies and Test Doubles
A production console build, dev CRM APIs, persona accounts and run-owned seeded records are real. Catalog-blocked journeys and tier-limited steps do not establish full proof.
Must Not Be Doubled
Keep the rendered components and request adapters real; replacing them would remove the console behavior under examination.
Fixtures and Isolation
Use run-owned records; serialize changes to shared configuration and restore the original values. Acceptance journeys use run-specific names and registered cleanup; shared configuration changes require the runner’s isolation project.
Determinism and Retries
The register records no new runtime result. Existing polling and fixture clocks remain part of the authored tests; polling for completion is not a retry of a failed case. Run with at most three workers and diagnose a failure before rerunning it.
How It Runs
The frontmatter records the scoped command and its runner tier. Supply the configuration and fixtures required by that Playwright project.
Coverage Gaps
Mapped scenarios retain their exact execution sources for review; combined multi-source scenarios can still leave an ordered handoff unproved. The capability gap records identify unbound obligations, and the grouped-suite finding records incomplete lifecycle and runtime coverage.