Files
amare/openspec/changes/build-public-site/specs/visual-regression/spec.md
Manoel Freitas 3dc1f449ee feat: ship public site with SEO and visuals (#3)
* feat: ship public site with SEO and visuals

Publish CMS content on public routes with responsive media,
accessibility checks, and deterministic visual baselines.

Co-authored-by: Cursor <cursoragent@cursor.com>

* fix: make browser visual CI deterministic for media

Mount host public storage into FrankenPHP so seeded fixtures are served,
and replace PNG-as-JPG fixtures with real JPEGs so Chromium can render them.

Co-authored-by: Cursor <cursoragent@cursor.com>

* fix: serve public media on same-origin storage paths

Pest Browser hosts on 127.0.0.1:port while Storage::url used
http://localhost, so screenshots captured broken images. Use relative
/storage URLs for media and absolutize only OG tags via url().

Co-authored-by: Cursor <cursoragent@cursor.com>

* test: refresh visual baselines from CI Ubuntu screenshots

Media now loads on same-origin /storage paths, so baselines must
capture the rendered fixtures. Use full-page snapshots from the CI
runner to keep Pest's exact snapshot match stable across environments.

Co-authored-by: Cursor <cursoragent@cursor.com>

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-29 10:12:24 -03:00

2.3 KiB
Raw Blame History

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 browser CI 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