CRM console fixture checks

Verification Boundary

The selected crm console fixture checks files cross the browser interaction boundary described below.

What This Suite Proves

Fixture-backed browser tests render affiliations, role editors, type changes, record creation and unchanged configuration departure. They establish visible interactions against supplied data. They do not establish stored CRM results and have no new acceptance scenario binding. No control is claimed without an independently mapped refusal case.

What It Does Not Prove

MSW responses cannot prove persistence, server permission refusal or reconciliation. A displayed created contact is a browser fixture outcome until a real backend stores and returns it. These checks must never be used to certify the real records lifecycle.

Level and Rationale

Browser rendering is required to establish interactions and layout under the selected fixtures. Pure component functions cannot establish the displayed composition. The absence of a real backend limits the level’s claim to presentation; choosing a browser runner does not make these fixtures end-to-end record proof.

Lifecycle Coverage

Create, change, delete and reconcile are not exercised against persisted CRM state. Their visible simulations do not cross that boundary. Archive is outside this selected fixture group; merge belongs to Data Quality. All applicable absent persisted lifecycles have findings, and live acceptance owns the real proof.

Real Dependencies and Test Doubles

The browser and rendered console components are real; fixture handlers supply CRM records and remote answers. This boundary does not include a real CRM database or service authorizer. The environment is mock, and the empty proof bindings prevent a fixture-rendered value from becoming a persistence claim.

Must Not Be Doubled

Keep the actual rendered components and browser interactions under test. Do not replace the editor’s state changes with precomputed screens. Fixture responses are explicitly allowed here, but they must stay identified as fixtures; no persisted record or server-side authority assertion may rely on them.

Fixtures and Isolation

Each browser context uses fixture-provided records and handler state, so its resets belong to the mock test harness. Fixture identifiers may resemble real identities but do not authorize writes to a development workspace. The selected list excludes other applications, duplicate review and explorer interactions.

Determinism and Retries

Fixture state is deterministic only within the harness setup documented by each file. The exact command disables retries and limits execution to one worker. A repeated fixture response cannot be reported as recovered backend persistence.

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. MSW responses cannot prove persistence, server permission refusal or reconciliation. A displayed created contact is a browser fixture outcome until a real backend stores and returns it. These checks must never be used to certify the real records lifecycle. Existing unbound files supply engineering observations; they do not silently implement additional capability or screen scenarios.