Controlled CRM console failures
Verification Boundary
The selected controlled crm console failures files cross the browser interaction boundary described below.
What This Suite Proves
The real console handles a supplied catalogue load failure, a partially refused bulk delete and a refused save while preserving typed values. The tests establish recovery controls and selection behavior under otherwise difficult response conditions. No control is claimed without an independently mapped refusal case.
What It Does Not Prove
An intercepted failure or partial-delete response cannot establish that the CRM service actually refuses, rolls back or deletes those records. The development catalogue suite and local API catalogue tests establish the adjacent live boundaries.
Level and Rationale
The error recovery experience belongs to the browser: retained fields, selection and retry actions cannot be established by a service refusal alone. A controlled response supplies a reproducible fault at that seam. It establishes client behavior while deliberately leaving the server cause outside the proof boundary.
Lifecycle Coverage
Create is not exercised as a persisted lifecycle. Change and delete are partial because the browser responds to supplied outcomes while the corresponding real service state is not established by that outcome. Archive and reconcile do not apply to this catalogue failure boundary. Merge belongs to Data Quality.
Real Dependencies and Test Doubles
The browser, sign-in and development console are real. The selected failure answer is intercepted at the exact seam named by the test. That supplied answer isolates browser recovery; the register does not attribute it to an actual server failure. Other interactions retain their source-declared live dependencies.
Must Not Be Doubled
Keep the real browser, catalogue editor and error handling. Intercept only the declared response. Replacing the save-failure presentation or selection state would bypass the behavior the test examines. A synthetic HTTP refusal must never be counted as proof of the service permission guard.
Fixtures and Isolation
The selected controlled project retains the real sign-in and console, with the deliberate response interception described by the test. Restore handlers after each case; a fixture response must not leak into a later live scenario. The command uses one worker to match the shared-session constraints.
Determinism and Retries
The load retry button is a product recovery action, distinct from rerunning a failed Playwright test. The registered command overrides the CI retry default to zero, so failures of the recovery behavior remain failures.
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. An intercepted failure or partial-delete response cannot establish that the CRM service actually refuses, rolls back or deletes those records. The development catalogue suite and local API catalogue tests establish the adjacent live boundaries. Existing unbound files supply engineering observations; they do not silently implement additional capability or screen scenarios.