CRM configuration layout fixtures
Verification Boundary
The selected crm configuration layout fixtures files cross the browser interaction boundary described below.
What This Suite Proves
The configuration layout fixtures inspect contact-type list presentation and organization-type editor geometry and interactions using browser-rendered components. They establish only their visual and interaction assertions under the fixture viewport. No control is claimed without an independently mapped refusal case.
What It Does Not Prove
A layout snapshot cannot establish stored catalogue creation, permission enforcement or deletion. It cannot certify a screen-reader audit or every viewport. Live configuration journeys own catalogue persistence; these fixtures are supplementary presentation evidence.
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 and delete are not exercised against persisted catalogues. Archive does not apply to classification presentation, and inactive display is a change. Reconcile is outside the layout proof boundary; merge belongs to Data Quality.
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
The layout harness supplies catalogue fixtures and isolates browser state. It owns generated screenshots and snapshot comparisons, not development CRM rows. Only the two Entities configuration files are selected; shell, form-engine and data-job layouts remain with their owning modules.
Determinism and Retries
The invocation fixes worker count and disables retries. Snapshot tolerances are whatever the pinned layout tests declare; this register invents no visual-fidelity threshold and reports no snapshot pass.
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 layout snapshot cannot establish stored catalogue creation, permission enforcement or deletion. It cannot certify a screen-reader audit or every viewport. Live configuration journeys own catalogue persistence; these fixtures are supplementary presentation evidence. Existing unbound files supply engineering observations; they do not silently implement additional capability or screen scenarios.