Manoel Freitas
2e43fdeb04
A cidade de atuação é São Paulo, garantida por teste em quatro lugares e exigida por openspec/specs/site-settings/spec.md. O identificador de timezone, porém, era America/Fortaleza. O identificador passa a acompanhar o negócio. A mudança não altera comportamento. America/Sao_Paulo e America/Fortaleza são UTC-3 o ano inteiro desde que o horário de verão brasileiro foi extinto — verificado para janeiro, março e dezembro de 2026, idênticos ao segundo. Nada renderizado muda, o relógio congelado dos testes visuais usa offset absoluto (-03:00) e os baselines seguem válidos. O motivo de mexer é outro: a divergência entre o timezone e a cidade custou tempo real. Uma sessão anterior a interpretou como drift e "corrigiu" a SPEC no sentido errado, mudando o documento normativo para Fortaleza em vez de olhar o que o negócio é. Com os dois valores dizendo São Paulo, não há mais o que interpretar. Escopo: config/app.php, .env.example, os dois pontos do ci.yml, SPEC.md (§0, §13.5, §15.4), README.md, docs/deployment/dokploy.md, CLAUDE.md, openspec/config.yaml, openspec/specs/visual-regression/spec.md e o withTimezone do VisualRegressionTest. Intocados de propósito: as asserções que garantem que Fortaleza não aparece como cidade de operação, em PublicPagesTest, SiteSettingsTest, ContentSeederProductionGatingTest e openspec/specs/site-settings. Essas tratam de cidade, não de fuso, e continuam corretas. Co-Authored-By: Claude noreply@anthropic.com AI-Assisted: yes AI-Tool: claude-code Co-authored-by: manoel.neto <manoel.neto@creditas.com>
61 lines
2.9 KiB
Markdown
61 lines
2.9 KiB
Markdown
# visual-regression Specification
|
||
|
||
## Purpose
|
||
Define deterministic visual baselines for public screens and the explicit baseline update workflow.
|
||
|
||
## 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, under the Heritage Editorial identity. A rendering change that alters those screens MUST fail the browser suite until the diff is reviewed and baselines are explicitly updated.
|
||
|
||
#### 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
|
||
|
||
#### Scenario: Heritage Editorial identity is captured
|
||
|
||
- **WHEN** approved baselines for the home are reviewed after this change
|
||
- **THEN** they MUST reflect EB Garamond typography, olive/paper palette and sharp-edged editorial layout rather than the previous gold/rounded placeholder look
|
||
|
||
### Requirement: Visual runs are deterministic
|
||
|
||
Visual runs SHALL be deterministic per SPEC §13.5: fixed Chromium and Linux image, fixed viewport, timezone `America/Sao_Paulo`, locale `pt-BR`, self-hosted fonts installed/bundled for the suite, frozen clock, deterministic seed (including real testimonial subset and São Paulo settings), 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
|