manoel freitas
9dd6fcf409
Archive completed public-site and production-provider changes into main specs, remove duplicate active changes, and add complete-foundation-parity so Phase 0 staging and remaining foundation gaps block Phase 2 cleanly. Co-authored-by: Cursor <cursoragent@cursor.com>
2.3 KiB
ADDED Requirements
Requirement: Public screens have desktop and mobile visual baselines
The system SHALL keep versioned screenshot baselines for the public screens available in this phase (SPEC §13.5): Home, Serviços, Portfólio and Detalhe do portfólio, at 1440×1000 desktop and 390×844 mobile. A rendering change that alters those screens MUST fail the browser suite until the diff is reviewed.
Scenario: Unintended visual change fails the suite
- GIVEN approved baselines exist
- WHEN a code change alters the rendering of a covered screen
- THEN the visual assertion MUST fail and report the diff
Scenario: Both viewports are covered
- WHEN the visual suite runs
- THEN each covered screen MUST be asserted at 1440×1000 and 390×844
Requirement: Visual runs are deterministic
Visual runs SHALL be deterministic per SPEC §13.5: fixed Chromium and Linux image, fixed viewport, timezone America/Fortaleza, locale pt-BR, fonts installed in the image, frozen clock, deterministic seed, animations and transitions disabled, and no dependency on external network.
Scenario: Repeated run without code change produces no diff
- WHEN the visual suite runs twice against the same commit and seed
- THEN both runs MUST pass with no pixel diff
Scenario: Time-dependent content does not cause drift
- GIVEN the clock is frozen and the seed is deterministic
- WHEN the suite runs on a different calendar day
- THEN rendered dates MUST remain identical to the baseline
Scenario: Motion is disabled during capture
- WHEN a screenshot is captured
- THEN CSS animations and transitions MUST be disabled
Requirement: Baseline updates are explicit and reviewed
Baselines SHALL only be updated through the explicit composer visual:update command, and the resulting diff MUST be reviewed by a human before merge. Baselines MUST NOT be regenerated automatically to make CI pass.
Scenario: CI does not regenerate baselines
- WHEN the
browserCI job runs - THEN it MUST run in assertion mode
- AND MUST NOT write new baselines
Scenario: Developer updates baselines intentionally
- WHEN a developer runs
composer visual:update - THEN the updated baseline files MUST be written to the versioned baseline directory for review