Files

Manoel Freitas 2e43fdeb04 chore: usar America/Sao_Paulo como timezone da aplicação (#42 )

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>

2026-08-10 11:37:03 -03:00

2.9 KiB

Raw Permalink Blame History

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

2.9 KiB Raw Permalink Blame History Unescape Escape