docs: archive recreate-public-frontend and sync Heritage Editorial specs
Merge delta requirements into main OpenSpec capabilities and move the completed change into the dated archive. Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-08-02
|
||||
@@ -0,0 +1,12 @@
|
||||
# Notes — recreate-public-frontend
|
||||
|
||||
## Remaining unresolved (do not invent)
|
||||
|
||||
- **Official contacts:** production e-mail is `amareassessoriaeventos@gmail.com`; WhatsApp and Instagram handles still placeholder until the owner confirms.
|
||||
- **Testimonial authorization:** five real couples from `depoimentos.md` are seeded for local/demo/visual; production publish still requires explicit couple authorization before `published_at` goes live.
|
||||
- **Authorized photography:** public images remain fixture/demo with editorial disclosure notes until Amare supplies an authorized portfolio archive.
|
||||
- **WEB-05 briefing form:** `/contato` stays presentation-only (channels + CTA); lead capture is a future change.
|
||||
|
||||
## Adaptation note
|
||||
|
||||
Mockup `amare-home-editorial.html` was single-page with anchors. Implementation keeps Laravel multipage routes; home carries the editorial narrative, internal pages are chapters with the same Heritage Editorial grammar.
|
||||
@@ -0,0 +1,158 @@
|
||||
## Context
|
||||
|
||||
O site público da Fase 1 já entrega rotas, CMS, SEO, mídia responsiva, regressão visual e acessibilidade. A identidade visual, porém, ainda é o placeholder da fundação: Instrument Sans, acento ouro, raios arredondados e cartões com sombra. `DESIGN.md` (“Heritage Editorial”), o mockup `amare-home-editorial.html`, o logo fornecido (coração facetado) e `depoimentos.md` (cinco casais reais) definem a marca a materializar.
|
||||
|
||||
Restrições que condicionam o desenho:
|
||||
|
||||
- Arquitetura multipágina Laravel/Blade/CMS já aprovada; o mockup HTML é single-page com âncoras — adaptar, não portar literalmente.
|
||||
- Contato permanece placeholder (WEB-05 fora de escopo); CTAs levam a `/contato` sem criar leads.
|
||||
- Fontes self-hosted via Vite (determinismo visual); sem Google Fonts CDN.
|
||||
- Imagens públicas via disco configurado + variantes; Unsplash do mockup não entra no app.
|
||||
- `PRODUCT.md`: São Paulo capital; seeders atuais ainda usam Fortaleza e depoimentos fictícios.
|
||||
- Change paralela `complete-foundation-parity` não bloqueia nem é bloqueada por esta.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
|
||||
- Materializar Heritage Editorial em todas as rotas públicas (home, serviços, portfólio, caso, sobre, contato, privacidade, 404, 500).
|
||||
- Home como capa do “Dossiê Editorial do Evento”: hero, manifesto, serviços, portfólio, método (4 passos), depoimentos reais, perfil Amare, CTA final.
|
||||
- Tokens centralizados alinhados a `DESIGN.md`; EB Garamond única família; radius 0; elevação por campos tonais.
|
||||
- Logo oficial otimizado (selo + lockup) em fundos claros/escuros, geometria preservada.
|
||||
- Cinco depoimentos de `depoimentos.md` no CMS/seed, multipárrafo, com nota de autorização.
|
||||
- Manter publicação dinâmica, paginação, eager loading, SEO, axe, teclado, contraste AA e baselines determinísticas.
|
||||
|
||||
**Non-Goals:**
|
||||
|
||||
- Briefing funcional / lead (WEB-05), WhatsApp automatizado, inventar provas corporativas.
|
||||
- Redesign do Filament, page builder, single-page navigation como modelo primário.
|
||||
- Fotografia proprietária real (permanece ilustrativa e marcada até acervo autorizado).
|
||||
- Staging/deploy/auth parity (`complete-foundation-parity`).
|
||||
|
||||
## Decisions
|
||||
|
||||
### D1 — Multipágina editorial, não single-page literal
|
||||
|
||||
Preservar rotas do SPEC §5.1. Home concentra a narrativa do mockup; páginas internas herdam a mesma gramática (eyebrow, títulos, linhas 1px, spreads assimétricos no desktop, sequência linear no mobile). Header usa links de rota (não `#âncoras` como navegação primária), com CTA “Solicitar proposta” → `contact`.
|
||||
|
||||
*Alternativas:* home quase idêntica com âncoras (rejeitada: conflita com SEO/CMS/rotas já testadas); portar HTML estático (rejeitada: perde CMS e determinismo).
|
||||
|
||||
### D2 — Tokens Heritage Editorial como única fonte visual
|
||||
|
||||
Reescrever `resources/css/tokens.css` e o mapeamento `@theme` em `app.css`:
|
||||
|
||||
| Papel | Token | Valor |
|
||||
|-------|-------|-------|
|
||||
| Fundo | `--amare-color-bg` | `#FBF9F4` (Papel Marfim) |
|
||||
| Fundo profundo | `--amare-color-bg-deep` | `#F0EEE9` |
|
||||
| Arquivo | `--amare-color-bg-archive` | `#E4E2DD` |
|
||||
| Oliva | `--amare-color-accent` | `#556B2F` |
|
||||
| Oliva profunda | `--amare-color-accent-deep` | `#3E5219` |
|
||||
| Sálvia | `--amare-color-sage` | `#8B9D77` |
|
||||
| Tinta | `--amare-color-text` | `#1B1C19` |
|
||||
| Tinta suave | `--amare-color-muted` | `#5D6155` |
|
||||
| Linha | `--amare-color-border` | `#C5C8B8` |
|
||||
| Radius | `--amare-radius-*` | `0` |
|
||||
| Container | `--amare-container-max` | `1120px` |
|
||||
| Sombra | removida / não usada em conteúdo | — |
|
||||
|
||||
Tipografia: EB Garamond (400/500/600) self-hosted via Vite; escala display/headline/title/body/label conforme `DESIGN.md`. Componentes públicos deixam de usar `rounded-*` e shadows de cartão.
|
||||
|
||||
*Alternativa:* CSS inline do mockup (rejeitada: foge de `design-tokens` e quebra Tailwind/`@theme`).
|
||||
|
||||
### D3 — Composição da home e omissão de seções vazias
|
||||
|
||||
Ordem canônica:
|
||||
|
||||
1. Hero (settings + imagem OG/hero se houver)
|
||||
2. Manifesto (copy de settings)
|
||||
3. Serviços em destaque (lista editorial, não grid de cartões)
|
||||
4. Portfólio em destaque (bloco escuro oliva; funde proof+cases atuais)
|
||||
5. Método (4 passos: Escuta, Direção, Produção, Execução)
|
||||
6. Depoimentos publicados
|
||||
7. Perfil / posicionamento Amare (about + princípios)
|
||||
8. CTA final → `/contato`
|
||||
|
||||
Seções alimentadas por collections (serviços, casos, depoimentos) **omitidas** quando vazias. Manifesto, método, perfil e CTA final permanecem (copy de settings / defaults editoriais). Um único `h1` no hero; demais seções usam `h2`/`h3`.
|
||||
|
||||
### D4 — Contato continua presentation-only
|
||||
|
||||
`/contato` e o CTA da home mostram canais de `site_settings` (e-mail, telefone, cidade, sociais). Nenhum `<form>` funcional, nenhum lead. O mockup de formulário serve só como referência visual futura para WEB-05; nesta change o bloco de contato da home é CTA editorial + link para a página de contato, não formulário embutido.
|
||||
|
||||
### D5 — Extensão mínima tipada de `site_settings`
|
||||
|
||||
Novos campos tipados (não key/value genérico):
|
||||
|
||||
- `logo_path` / `logo_alt` (opcional; fallback para lockup estático em `public/`)
|
||||
- `hero_secondary_cta_label` (opcional)
|
||||
- `hero_note` (texto curto sob CTAs)
|
||||
- `manifesto_title`, `manifesto_lead`, `manifesto_body`
|
||||
- `method_intro` (opcional; passos estruturados em JSON tipado ou colunas `method_step_{1..4}_{title,body}` — preferir JSONB `method_steps` validado no Filament)
|
||||
- `principles` (JSONB lista de até 4 strings) **ou** quatro colunas `principle_1..4`
|
||||
- Manter `about_summary`, hero atual, contato, SEO, analytics
|
||||
|
||||
Filament `ManageSiteSettings` ganha seções editoriais em pt-BR. Defaults no seeder alinhados ao mockup + São Paulo.
|
||||
|
||||
*Alternativa:* hardcode de manifesto/método nas Blade (rejeitada parcialmente: método/princípios podem ter default no view, mas copy institucional deve ser editável como o hero).
|
||||
|
||||
### D6 — Logo: ativo estático + campo CMS opcional
|
||||
|
||||
1. Converter/otimizar o PNG fornecido para WebP/SVG derivados em `public/brand/` (selo coração + lockup completo), com versões para fundo claro (oliva) e fundo escuro (papel/branco).
|
||||
2. Componente `<x-brand.logo>` escolhe variante por contexto (`on-dark` / `on-light`) e expõe `alt` acessível.
|
||||
3. Se `logo_path` em settings estiver preenchido, usa o upload; senão, o estático versionado.
|
||||
|
||||
Não redesenhar o coração facetado; não inventar polígonos decorativos genéricos.
|
||||
|
||||
### D7 — Depoimentos reais multipárrafo
|
||||
|
||||
- Seedar os 5 casais de `depoimentos.md` em `quote` (texto completo com quebras `\n\n`), `author_name`, `context` (ex.: `Casamento · 06/12/2025`), `sort_order`, `is_featured`, `published_at` conforme ambiente.
|
||||
- Blade renderiza parágrafos a partir de quebras de linha; tipografia editorial (aspas, offset).
|
||||
- Nota discreta no markup/admin: autorização final dos casais antes de publicação em produção.
|
||||
- Remover depoimentos fictícios dos seeders de demo/visual ou substituí-los pelos reais (visual seeder usa subset determinístico, tipicamente 2 featured).
|
||||
|
||||
### D8 — Navegação responsiva com JS mínimo
|
||||
|
||||
`resources/js/app.js` ganha toggle de menu mobile (aria-expanded, `menu-open`, fechar ao navegar), espelhando o mockup. Sem framework novo. `prefers-reduced-motion` continua a anular transições não essenciais. Hover de imagem (scale leve) só quando motion permitido.
|
||||
|
||||
### D9 — Páginas internas como capítulos
|
||||
|
||||
| Rota | Tratamento |
|
||||
|------|------------|
|
||||
| `/servicos` | Lista editorial (número + nome + resumo), não cartões |
|
||||
| `/portfolio` | Grade assimétrica / stack com captions; fundo pode usar papel profundo |
|
||||
| `/portfolio/{slug}` | Caderno de caso: metadados, desafio/solução/resultado, galeria |
|
||||
| `/sobre` | Perfil editorial + princípios |
|
||||
| `/contato` | Canais + CTA textual (sem form) |
|
||||
| `/privacidade` | Tipografia editorial sobre papel |
|
||||
| 404/500 | Mesma linguagem; 500 sem internals |
|
||||
|
||||
### D10 — Testes e baselines
|
||||
|
||||
- Atualizar feature tests de home (ordem de seções, omissão, CTA → contact, `data-testid="home-primary-cta"`).
|
||||
- Browser: axe nas rotas cobertas; Tab até CTA; console limpo.
|
||||
- `composer visual:update` após aprovação visual local; timezone permanece `America/Fortaleza` (SPEC); copy de cidade pública passa a São Paulo.
|
||||
- Fotos fixture locais continuam; filtro CSS de saturação contida via classe utilitária, não via URL externa.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- **Regeneração de 8+ snapshots** → risco de ruído no PR; mitigar com seeder visual estável e revisão humana do diff.
|
||||
- **EB Garamond em forms/UI** → legibilidade de labels uppercase; mitigar com letter-spacing e peso 600 conforme DESIGN.md; validar contraste AA.
|
||||
- **Depoimentos longos** → layout quebra em mobile; mitigar com tipografia responsiva e subset featured na home.
|
||||
- **Autorização de depoimentos** → risco legal/reputacional; mitigar com nota explícita e `published_at` null até autorização.
|
||||
- **Campos novos em site_settings** → migração + Filament; mitigar com defaults e nullable.
|
||||
- **Paridade com mockup single-page** → expectativa visual vs rotas; documentar adaptação multipágina na proposta e no surface brief.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
1. Migrar tokens/fontes/logo estático (sem breaking de rotas).
|
||||
2. Migrar `site_settings` (colunas novas nullable + backfill de defaults).
|
||||
3. Atualizar seeders (SP + depoimentos reais).
|
||||
4. Trocar layout e páginas; manter contratos de testes passando incrementalmente.
|
||||
5. Regenerar baselines com `composer visual:update`.
|
||||
6. Rollback: reverter deploy/commit; migração down remove colunas novas; assets estáticos são aditivos.
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Formato exato de `method_steps` / `principles` (JSONB vs colunas) — default recomendado: JSONB validado no Filament.
|
||||
- WhatsApp/e-mail/Instagram oficiais ainda ausentes — settings continuam placeholder até o dono informar.
|
||||
- Subconjunto de depoimentos na home (2 vs 5) — default: featured first, até 2 na home estilo mockup; listagem completa só se houver página dedicada (não há); home mostra todos published featured ou os N primeiros por `sort_order` (cap 2–3 para ritmo editorial).
|
||||
@@ -0,0 +1,49 @@
|
||||
## Why
|
||||
|
||||
O site público já existe com rotas, CMS e gates de qualidade, mas a identidade visual ainda é o placeholder da Fase 0 (Instrument Sans, ouro, cantos arredondados, cartões genéricos). `DESIGN.md` e o mockup editorial já definem o sistema Heritage Editorial; `depoimentos.md` e o logo fornecido finalmente permitem prova e marca reais. Sem recriar o frontend agora, o critério de saída da Fase 1 (“site público aprovado visualmente”) permanece ligado a uma UI que não representa a marca, e a Fase 2 (WEB-05) herdaria um shell genérico.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Substituir tokens, tipografia e composição do site público pelo sistema **Heritage Editorial** de `DESIGN.md` (EB Garamond, oliva/papel, cantos retos, campos tonais, sem sombras de cartão SaaS).
|
||||
- Adaptar o mockup `amare-home-editorial.html` à arquitetura **multipágina** Laravel/CMS existente: home como capa editorial; serviços, portfólio, caso, sobre, contato, privacidade e erros como capítulos coerentes.
|
||||
- Incorporar o logo fornecido (coração facetado + lockup) como ativo otimizado com variantes para fundos claros/escuros, sem redesenhar a geometria.
|
||||
- Seedar e renderizar os **cinco depoimentos reais** de `depoimentos.md` (texto, casal, data/contexto), com autorização final como requisito de publicação.
|
||||
- Reestruturar a home na narrativa editorial: hero → manifesto → serviços → portfólio → método → depoimentos → perfil Amare → CTA final (WEB-01).
|
||||
- Atualizar layout público (header/footer, navegação responsiva, selo), componentes Blade e páginas internas para a mesma linguagem visual.
|
||||
- Estender `site_settings` o mínimo necessário para copy editorial (manifesto, nota do hero, CTA secundário, passos do método, princípios) mantendo singleton tipado (WEB-06).
|
||||
- Regenerar baselines visuais desktop/mobile e manter axe, teclado, landmarks, SEO e publicação dinâmica (SPEC §6.5, §13.5, §13.8).
|
||||
- Atualizar seeders/conteúdo demonstrativo para São Paulo e marcar fotografias ilustrativas até existir acervo autorizado.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
Conforme [SPEC.md §4.2](../../SPEC.md) e decisões desta proposta:
|
||||
|
||||
- Formulário funcional de briefing / criação de lead (WEB-05) — permanece placeholder em `/contato`; change futura `build-lead-capture`.
|
||||
- Integração WhatsApp, portal do cliente, page builder, i18n, PWA.
|
||||
- Inventar cases corporativos, credenciais, números, imprensa ou provas não autorizadas.
|
||||
- Redesign do painel Filament / área interna.
|
||||
- Deploy staging / paridade de fundação — change paralela `complete-foundation-parity`, independente desta.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
|
||||
<!-- Nenhuma capability nova: a recriação altera requisitos de capabilities já existentes. -->
|
||||
|
||||
### Modified Capabilities
|
||||
|
||||
- `design-tokens`: substituir tokens placeholder (Instrument Sans, ouro, raios, sombras) pelos tokens Heritage Editorial (EB Garamond, oliva/papel, radius 0, elevação tonal).
|
||||
- `public-site-pages`: reestruturar home editorial e páginas públicas para a composição “Dossiê Editorial do Evento”, preservando rotas e publicação.
|
||||
- `site-settings`: campos tipados adicionais para copy editorial da home (manifesto, CTAs, método, princípios, logo).
|
||||
- `testimonials`: suporte a depoimentos multipárrafo reais com contexto/data e regra de autorização antes da publicação.
|
||||
- `content-media`: logo da marca e tratamento editorial de imagens demonstrativas (marcação, filtros contidos) sem inventar acervo.
|
||||
- `visual-regression`: baselines regeneradas sob a nova identidade; determinismo e cobertura de telas mantidos.
|
||||
- `web-accessibility`: preservação/reforço de landmarks, foco, teclado, contraste AA e movimento reduzido após a troca tipográfica/cromática.
|
||||
|
||||
## Impact
|
||||
|
||||
- **Altera**: `resources/css/tokens.css`, `resources/css/app.css`, `vite.config.js`, `resources/views/layouts/public.blade.php`, `resources/views/pages/**`, `resources/views/components/home/**`, `resources/js/app.js`, seeders (`ContentSeeder`, `VisualContentSeeder`), possivelmente migração + model/Filament de `site_settings`, testes Feature/Browser e snapshots em `tests/.pest/snapshots/`.
|
||||
- **Cria**: ativo de logo em `public/` (ou storage CMS), componentes Blade de marca/manifesto/positioning, campos tipados novos em `site_settings` se necessário.
|
||||
- **Depende de**: specs atuais `design-tokens`, `public-site-pages`, `site-settings`, `testimonials`, `content-media`, `visual-regression`, `web-accessibility`, `public-seo`, `service-catalog`, `portfolio-cases`.
|
||||
- **Independente de**: `complete-foundation-parity` (auth/staging/coverage).
|
||||
- **Risco**: regeneração ampla de snapshots; mitigado por seed determinístico, fontes self-hosted e `composer visual:update` com revisão humana. Depoimentos reais exigem confirmação de autorização antes de publicar em produção.
|
||||
@@ -0,0 +1,31 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Brand logo assets are available to the public layout
|
||||
|
||||
The system SHALL provide optimized Amare brand logo assets derived from the official faceted-heart lockup for use in the public header, footer and institutional pages. Assets MUST preserve the original geometry, include an accessible text alternative, and provide variants suitable for light and dark tonal fields. When `site_settings.logo_path` is present, the uploaded logo MUST be used; otherwise the versioned static brand asset MUST be used.
|
||||
|
||||
#### Scenario: Header renders brand mark with alt text
|
||||
|
||||
- **WHEN** any public page is rendered
|
||||
- **THEN** the brand mark image or equivalent MUST expose accessible alternative text identifying Amare Assessoria
|
||||
|
||||
#### Scenario: Dark portfolio field uses a legible logo variant
|
||||
|
||||
- **WHEN** the brand mark is rendered on an olive-deep or otherwise dark public surface
|
||||
- **THEN** the chosen logo variant MUST remain legible against that background
|
||||
|
||||
#### Scenario: Uploaded logo overrides static fallback
|
||||
|
||||
- **GIVEN** an admin has saved `logo_path` and `logo_alt` in site settings
|
||||
- **WHEN** the public layout renders the brand mark
|
||||
- **THEN** the uploaded logo MUST be used instead of the static fallback
|
||||
|
||||
### Requirement: Editorial image treatment remains self-hosted and deterministic
|
||||
|
||||
Public photography SHALL continue to use validated self-hosted uploads and responsive variants. Decorative saturation/contrast treatment for editorial mood MUST be applied via CSS on self-hosted images and MUST NOT introduce external image CDN dependencies that break deterministic visual tests.
|
||||
|
||||
#### Scenario: Public pages do not depend on external stock hosts
|
||||
|
||||
- **WHEN** the visual or browser suite loads covered public routes
|
||||
- **THEN** content images MUST resolve from the application media disk or static fixtures
|
||||
- **AND** MUST NOT require network access to third-party stock hosts
|
||||
@@ -0,0 +1,53 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Design tokens are centralized for the public site
|
||||
|
||||
The system SHALL define design tokens in a single source consumed by the public site layout and components. Tokens MUST implement the Heritage Editorial system from `DESIGN.md`: typography family EB Garamond (self-hosted), font scale (display/headline/title/body/label), spacing on an 8px rhythm, border radius `0` for interactive and content surfaces, container max width `1120px`, paper/olive/sage/ink color roles, transition duration/easing, and MUST NOT rely on card shadows as a hierarchy mechanism for regular content.
|
||||
|
||||
#### Scenario: Public layout uses shared Heritage Editorial tokens
|
||||
|
||||
- **WHEN** a public page is rendered
|
||||
- **THEN** visual properties MUST be derived from the centralized token definitions rather than arbitrary inline values
|
||||
- **AND** the primary typeface MUST be EB Garamond (or the declared serif fallback stack)
|
||||
- **AND** public content surfaces MUST use `0` border radius from tokens
|
||||
|
||||
#### Scenario: Palette commits paper and olive regions
|
||||
|
||||
- **WHEN** the public site is rendered
|
||||
- **THEN** background regions MUST use paper ivory / paper deep / olive deep tokens rather than pure white card stacks on a white page
|
||||
- **AND** primary interactive emphasis MUST use olive heritage (`#556B2F`) / olive deep (`#3E5219`) tokens
|
||||
|
||||
### Requirement: Public site respects reduced motion preference
|
||||
|
||||
The system SHALL honor `prefers-reduced-motion` by disabling or minimizing non-essential animations and transitions on the public site, including image hover scales and menu transitions.
|
||||
|
||||
#### Scenario: User prefers reduced motion
|
||||
|
||||
- **WHEN** a visitor has `prefers-reduced-motion: reduce` enabled
|
||||
- **THEN** the public site MUST NOT play non-essential motion effects
|
||||
|
||||
### Requirement: Public site meets baseline accessibility contrast
|
||||
|
||||
The system SHALL use Heritage Editorial color combinations that meet WCAG AA contrast requirements for text and interactive elements. Long-form text MUST use ink on paper; sage MUST NOT replace reading color when contrast would fall below AA.
|
||||
|
||||
#### Scenario: Primary text is readable
|
||||
|
||||
- **WHEN** primary body text is rendered on its background color
|
||||
- **THEN** the contrast ratio MUST meet WCAG AA minimums
|
||||
|
||||
#### Scenario: Olive on paper interactive text is readable
|
||||
|
||||
- **WHEN** primary buttons or links use olive tokens on paper backgrounds (or paper text on olive)
|
||||
- **THEN** the contrast ratio MUST meet WCAG AA minimums
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Elevation comes from tonal fields not card shadows
|
||||
|
||||
The public site SHALL express hierarchy through tonal paper fields, 1px botanical rules, and editorial overlap. Regular content components MUST NOT use short grey SaaS card shadows.
|
||||
|
||||
#### Scenario: Content cards omit drop shadows
|
||||
|
||||
- **WHEN** home services, testimonials, or portfolio items are rendered
|
||||
- **THEN** they MUST NOT depend on `--amare-shadow-*` card elevation for hierarchy
|
||||
- **AND** separation MUST come from borders, tonal backgrounds, or whitespace
|
||||
@@ -0,0 +1,107 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Home renders the editorial structure from CMS content
|
||||
|
||||
The home page SHALL render, in order: header/navigation, hero, manifesto, featured services summary, featured portfolio selection, working method (four steps), testimonials, Amare positioning/profile, final contact CTA, and footer with contact, social links and legal links (WEB-01). Hero copy, brand name, manifesto, method and principles MUST come from `site_settings` (with editorial defaults when optional fields are empty); services, cases and testimonials MUST come from published records. The home MUST follow the Heritage Editorial composition (asymmetric spreads on desktop, linear sequence on mobile) rather than rounded card grids.
|
||||
|
||||
#### Scenario: Published content is displayed in configured order
|
||||
|
||||
- **GIVEN** published services, cases and testimonials exist
|
||||
- **WHEN** a visitor loads the home
|
||||
- **THEN** the published content MUST be displayed following the `sort_order` and featured flags
|
||||
- **AND** the hero MUST show the values stored in `site_settings`
|
||||
- **AND** the manifesto, method and positioning sections MUST be present
|
||||
|
||||
#### Scenario: CTA leads to the contact placeholder page
|
||||
|
||||
- **WHEN** a visitor activates the primary or final CTA on the home
|
||||
- **THEN** the visitor MUST be taken to the `contact` route
|
||||
- **AND** no lead record MUST be created
|
||||
|
||||
#### Scenario: Empty catalog sections are omitted
|
||||
|
||||
- **GIVEN** no published services, cases or testimonials
|
||||
- **WHEN** a visitor loads the home
|
||||
- **THEN** the response MUST be 200
|
||||
- **AND** the services, portfolio and testimonials sections MUST be omitted instead of rendering empty containers
|
||||
- **AND** hero, manifesto, method, positioning and final CTA MUST still render
|
||||
|
||||
#### Scenario: Home has no console errors
|
||||
|
||||
- **WHEN** the home is loaded in a real browser at desktop and mobile viewports
|
||||
- **THEN** the browser console MUST contain no JavaScript errors
|
||||
|
||||
### Requirement: Listing and detail pages exist for catalog content
|
||||
|
||||
The system SHALL render a services listing (WEB-02) and a portfolio listing plus case detail (WEB-03) using the Heritage Editorial visual language. The case detail MUST present summary, event type, optional city/venue/date, challenge, solution, optional result, cover image and the ordered gallery.
|
||||
|
||||
#### Scenario: Services listing shows published services
|
||||
|
||||
- **WHEN** a visitor loads `/servicos`
|
||||
- **THEN** every published service MUST be listed with title and summary in `sort_order`
|
||||
- **AND** the listing MUST use the public editorial layout (not an unrelated visual system)
|
||||
|
||||
#### Scenario: Gallery respects stored order
|
||||
|
||||
- **GIVEN** a published case with multiple gallery images
|
||||
- **WHEN** a visitor loads the case detail
|
||||
- **THEN** the images MUST be rendered ordered by `sort_order`
|
||||
|
||||
#### Scenario: Listings paginate open-ended growth
|
||||
|
||||
- **WHEN** the number of published cases exceeds the page size
|
||||
- **THEN** `/portfolio` MUST paginate instead of rendering all records
|
||||
|
||||
### Requirement: Institutional and error pages have brand identity
|
||||
|
||||
The system SHALL provide the Sobre and Política de privacidade pages and branded error pages (WEB-07) using the Heritage Editorial public layout, including the brand mark when available. The 404 page MUST use the public layout, and the 500 page MUST NOT expose stack traces or internal details when `APP_DEBUG` is false.
|
||||
|
||||
#### Scenario: Unknown URL renders branded 404
|
||||
|
||||
- **WHEN** a visitor requests a non-existent public URL
|
||||
- **THEN** the response status MUST be 404
|
||||
- **AND** the page MUST use the public layout and offer navigation back to the home
|
||||
|
||||
#### Scenario: Server error hides internals in production
|
||||
|
||||
- **GIVEN** `APP_DEBUG` is false
|
||||
- **WHEN** an unhandled exception occurs on a public route
|
||||
- **THEN** the response MUST be a generic branded error page
|
||||
- **AND** MUST NOT contain a stack trace, file path, or environment variable
|
||||
|
||||
### Requirement: Contact page presents contact data as briefing placeholder
|
||||
|
||||
The `contact` route SHALL render the contact page using `site_settings` (e-mail, phone, city, social links) so the home CTA has a valid destination before the briefing form exists. The page MUST NOT create leads and MUST NOT submit a functional briefing form in this change.
|
||||
|
||||
#### Scenario: Contact page shows configured contact data
|
||||
|
||||
- **WHEN** a visitor loads `/contato`
|
||||
- **THEN** the e-mail and phone stored in `site_settings` MUST be displayed
|
||||
- **AND** no lead record MUST be created
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Public header exposes brand mark and responsive navigation
|
||||
|
||||
The public layout SHALL render the Amare brand mark (faceted-heart logo lockup or configured logo), primary route navigation, and a contact CTA. On narrow viewports the navigation MUST be operable via a disclosure control with accessible name and `aria-expanded` state.
|
||||
|
||||
#### Scenario: Desktop header shows navigation and CTA
|
||||
|
||||
- **WHEN** a visitor loads any public page at a desktop viewport
|
||||
- **THEN** the header MUST include brand mark, links to home/services/portfolio/about/contact, and a contact CTA
|
||||
|
||||
#### Scenario: Mobile menu toggles accessibly
|
||||
|
||||
- **WHEN** a visitor activates the menu button on a narrow viewport
|
||||
- **THEN** the primary navigation MUST become available
|
||||
- **AND** the control MUST expose an updated `aria-expanded` value
|
||||
- **AND** activating a navigation link MUST close the menu
|
||||
|
||||
### Requirement: Demonstrative photography is labeled until authorized assets exist
|
||||
|
||||
When public pages render illustrative/demo photography that is not an authorized Amare asset, the system SHALL mark that imagery as demonstrative in visible copy or accessible labeling so visitors are not misled.
|
||||
|
||||
#### Scenario: Portfolio demo imagery is disclosed
|
||||
|
||||
- **WHEN** the home or portfolio renders placeholder photography
|
||||
- **THEN** a visible note or equivalent disclosure MUST indicate the imagery is illustrative pending authorized assets
|
||||
@@ -0,0 +1,53 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Site settings singleton is manageable by admin only
|
||||
|
||||
The system SHALL persist site-wide settings in a `site_settings` table as a typed singleton (SPEC WEB-06, §8.2). Fields MUST include brand name, optional logo path and logo alt text, hero copy (eyebrow, title, subtitle, primary CTA label, optional secondary CTA label, optional hero note), manifesto copy (title, lead, body), method steps (structured typed data for four editorial steps), principles (structured typed list), about summary, contact email/phone/city, social links (jsonb), default meta title/description, default OG image path and alt text, and optional analytics fields disabled by default.
|
||||
|
||||
#### Scenario: Admin updates site settings
|
||||
|
||||
- **WHEN** an admin saves the site settings form in Filament
|
||||
- **THEN** the singleton record is updated
|
||||
- **AND** labels and validation messages are in pt-BR
|
||||
|
||||
#### Scenario: Assistant cannot access site settings
|
||||
|
||||
- **WHEN** an assistant navigates to site settings in Filament
|
||||
- **THEN** access MUST be denied with HTTP 403
|
||||
|
||||
#### Scenario: Default OG image requires alt text
|
||||
|
||||
- **WHEN** an admin uploads a default OG image without alt text
|
||||
- **THEN** validation MUST fail with a pt-BR error message
|
||||
- **AND** alt text MUST remain optional when no default OG image is present
|
||||
|
||||
#### Scenario: Logo upload requires alt text
|
||||
|
||||
- **WHEN** an admin uploads a brand logo without alt text
|
||||
- **THEN** validation MUST fail with a pt-BR error message
|
||||
- **AND** alt text MUST remain optional when no logo is uploaded
|
||||
|
||||
#### Scenario: Singleton avoids generic key-value store
|
||||
|
||||
- **WHEN** site settings are stored
|
||||
- **THEN** the system MUST use typed columns on `site_settings`
|
||||
- **AND** MUST NOT introduce a generic key/value configuration table
|
||||
|
||||
#### Scenario: Editorial defaults remain available when optional fields are empty
|
||||
|
||||
- **GIVEN** manifesto, method steps or principles fields are empty
|
||||
- **WHEN** the home is rendered
|
||||
- **THEN** the page MUST still render those sections using safe editorial defaults
|
||||
- **AND** MUST NOT error
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Public geography defaults to São Paulo
|
||||
|
||||
Demo and visual seed content for site settings SHALL present the Amare operating city as São Paulo (capital), matching `PRODUCT.md`, instead of unrelated cities.
|
||||
|
||||
#### Scenario: Seeded settings use São Paulo
|
||||
|
||||
- **WHEN** content seeders populate `site_settings`
|
||||
- **THEN** the city field MUST be São Paulo (or equivalent capital wording)
|
||||
- **AND** MUST NOT present Fortaleza as the operating city
|
||||
@@ -0,0 +1,47 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Testimonials are managed with publication control
|
||||
|
||||
The system SHALL allow admins to manage testimonials (SPEC WEB-04) with quote text (including multi-paragraph content), author name, optional context (event type and/or date), optional photo with alt text, sort order, featured flag, and `published_at`. Public rendering MUST preserve paragraph breaks from the stored quote. Testimonials sourced from real clients MUST NOT be published to production without authorization; development seeds MAY include the authorized-pending real quotes marked for review.
|
||||
|
||||
#### Scenario: Unpublished testimonial is excluded
|
||||
|
||||
- **WHEN** a testimonial has `published_at` null
|
||||
- **THEN** the `published()` scope MUST exclude it
|
||||
|
||||
#### Scenario: Published testimonial is queryable
|
||||
|
||||
- **WHEN** an admin sets `published_at` with required quote and author name
|
||||
- **THEN** the testimonial MUST be included in the `published()` scope
|
||||
|
||||
#### Scenario: Assistant cannot manage testimonials
|
||||
|
||||
- **WHEN** an assistant attempts to access the testimonials Resource
|
||||
- **THEN** access MUST be denied with HTTP 403
|
||||
|
||||
#### Scenario: Featured testimonials are filterable
|
||||
|
||||
- **WHEN** content is queried with featured filter
|
||||
- **THEN** records with `is_featured` true MUST be retrievable independently of sort order
|
||||
|
||||
#### Scenario: Multi-paragraph quotes render as paragraphs
|
||||
|
||||
- **GIVEN** a published testimonial whose quote contains blank-line separated paragraphs
|
||||
- **WHEN** the home testimonials section is rendered
|
||||
- **THEN** each paragraph MUST appear as distinct block text rather than a single collapsed line
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Real wedding testimonials are seeded from authorized source copy
|
||||
|
||||
Content and visual seeders SHALL replace fictional testimonials with the five real wedding testimonials from `depoimentos.md`, preserving author couple names, quote wording, and date/context. Until final publication authorization is confirmed, production deployments MUST keep those records unpublished or gated by explicit admin publish action.
|
||||
|
||||
#### Scenario: Seed loads the five real couples
|
||||
|
||||
- **WHEN** the content seeder runs
|
||||
- **THEN** testimonials for Jeniffer e Maick, Quesia e Jhonata, Milena e Weslley, Raquel e Pedro, and Victoria e Pedro MUST exist with their source quotes and marriage context/dates
|
||||
|
||||
#### Scenario: Fictional demo quotes are removed
|
||||
|
||||
- **WHEN** the content seeder completes
|
||||
- **THEN** previously invented placeholder testimonial authors MUST NOT remain as the published demo set
|
||||
@@ -0,0 +1,56 @@
|
||||
## MODIFIED 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/Fortaleza`, 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
|
||||
@@ -0,0 +1,79 @@
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Public routes have no critical or serious accessibility issues
|
||||
|
||||
The system SHALL run automated accessibility checks on the public routes covered by the browser suite (SPEC §6.5, §13.8) after the Heritage Editorial redesign. A critical or serious issue MUST fail the suite.
|
||||
|
||||
#### Scenario: Critical issue blocks the suite
|
||||
|
||||
- **WHEN** the automated accessibility check reports a critical or serious issue on a covered route
|
||||
- **THEN** the browser suite MUST fail and report the offending rule and selector
|
||||
|
||||
#### Scenario: Covered routes are checked
|
||||
|
||||
- **WHEN** the accessibility suite runs
|
||||
- **THEN** the home, services listing, portfolio listing and case detail MUST each be checked
|
||||
|
||||
### Requirement: Public pages use accessible semantic structure
|
||||
|
||||
Public pages SHALL provide semantic landmarks, exactly one `h1` per page, a coherent heading order, alt text on every content image and brand mark, and visible focus on interactive elements (SPEC §6.5).
|
||||
|
||||
#### Scenario: Single h1 per page
|
||||
|
||||
- **WHEN** any public page is rendered
|
||||
- **THEN** exactly one `h1` element MUST be present
|
||||
|
||||
#### Scenario: Landmarks are present
|
||||
|
||||
- **WHEN** any public page is rendered
|
||||
- **THEN** `header`, `main`, `nav` and `footer` landmarks MUST be present
|
||||
|
||||
#### Scenario: Content images expose alt text
|
||||
|
||||
- **WHEN** a page renders a cover or gallery image
|
||||
- **THEN** the `alt` attribute MUST contain the stored alt text
|
||||
|
||||
#### Scenario: Brand mark exposes accessible name
|
||||
|
||||
- **WHEN** the public header brand mark is rendered
|
||||
- **THEN** it MUST expose an accessible name identifying Amare Assessoria
|
||||
|
||||
### Requirement: Public pages are fully keyboard operable
|
||||
|
||||
Visitors SHALL be able to reach and activate every interactive element with the keyboard, including the mobile navigation disclosure when visible, with a visible focus indicator and a skip link to the main content.
|
||||
|
||||
#### Scenario: Keyboard reaches the primary CTA
|
||||
|
||||
- **WHEN** a visitor navigates the home with the Tab key
|
||||
- **THEN** the primary CTA MUST receive focus with a visible indicator
|
||||
- **AND** activating it with the keyboard MUST navigate to the contact route
|
||||
|
||||
#### Scenario: Skip link bypasses navigation
|
||||
|
||||
- **WHEN** a visitor focuses the first element of a public page
|
||||
- **THEN** a skip link to the main content MUST be available
|
||||
|
||||
#### Scenario: Mobile menu is keyboard operable
|
||||
|
||||
- **WHEN** the mobile menu button is focused and activated with the keyboard
|
||||
- **THEN** the navigation links MUST become reachable by subsequent Tab stops
|
||||
- **AND** the button MUST expose the correct `aria-expanded` state
|
||||
|
||||
### Requirement: Reduced motion preference is honored
|
||||
|
||||
The system SHALL suppress non-essential animation and transition when the user agent reports `prefers-reduced-motion: reduce`, including editorial hover scales and menu transitions introduced by the redesign.
|
||||
|
||||
#### Scenario: Reduced motion disables transitions
|
||||
|
||||
- **GIVEN** the browser reports `prefers-reduced-motion: reduce`
|
||||
- **WHEN** a public page is loaded
|
||||
- **THEN** decorative transitions and animations MUST NOT run
|
||||
|
||||
### Requirement: Public pages emit no console errors
|
||||
|
||||
Covered public routes SHALL load without JavaScript console errors in a real browser (SPEC §13.8, §19), including pages that load the mobile navigation script.
|
||||
|
||||
#### Scenario: Console stays clean on covered routes
|
||||
|
||||
- **WHEN** a covered public route is loaded in the browser suite
|
||||
- **THEN** the console MUST contain no error-level messages
|
||||
@@ -0,0 +1,57 @@
|
||||
## 1. Tokens, fonts and brand assets
|
||||
|
||||
- [x] 1.1 Write failing feature/CSS contract tests (or extend existing token/layout assertions) for Heritage Editorial palette, EB Garamond family, radius 0 and container `1120px`
|
||||
- [x] 1.2 Rewrite `resources/css/tokens.css` + `@theme` mapping in `app.css` to Heritage Editorial; remove card-shadow hierarchy for public content
|
||||
- [x] 1.3 Swap Vite font from Instrument Sans to self-hosted EB Garamond (400/500/600) and update `components/fonts.blade.php` consumption
|
||||
- [x] 1.4 Add optimized logo assets under `public/brand/` (light/dark variants) from the provided lockup without redrawing geometry; add `<x-brand.logo>` with accessible alt
|
||||
- [x] 1.5 Run focused feature/static checks covering tokens/fonts and `npm run build`
|
||||
|
||||
## 2. Site settings and CMS editorial fields
|
||||
|
||||
- [x] 2.1 Add failing feature tests for new typed `site_settings` fields (logo, hero secondary CTA/note, manifesto, method steps, principles) and São Paulo seed city
|
||||
- [x] 2.2 Create migration + model fillable/casts for the new typed columns (JSONB for method steps/principles preferred)
|
||||
- [x] 2.3 Update Filament `ManageSiteSettings` with pt-BR editorial sections and logo alt validation
|
||||
- [x] 2.4 Update `ContentSeeder` / factory defaults with editorial copy and São Paulo; keep optional fields nullable with safe view defaults
|
||||
- [x] 2.5 Run `composer test:feature` for site-settings coverage
|
||||
|
||||
## 3. Real testimonials
|
||||
|
||||
- [x] 3.1 Add failing tests for multi-paragraph quote rendering and seeder expectations for the five couples from `depoimentos.md`
|
||||
- [x] 3.2 Replace fictional testimonials in content/visual seeders with the real quotes, author names and context/dates
|
||||
- [x] 3.3 Update testimonials Blade to render paragraph breaks; keep unpublished-by-default path documented for production authorization
|
||||
- [x] 3.4 Run testimonials feature tests
|
||||
|
||||
## 4. Public layout and navigation
|
||||
|
||||
- [x] 4.1 Add/extend failing tests for brand mark in header, landmarks, skip link, and mobile menu `aria-expanded` behavior
|
||||
- [x] 4.2 Redesign `layouts/public.blade.php` header/footer for Heritage Editorial (logo, route nav, contact CTA, footer groups)
|
||||
- [x] 4.3 Implement minimal mobile menu toggle in `resources/js/app.js` with reduced-motion safety
|
||||
- [x] 4.4 Run layout/accessibility structure feature tests
|
||||
|
||||
## 5. Home editorial reconstruction
|
||||
|
||||
- [x] 5.1 Update failing `HomePageContentTest` (and related) for new section order: hero → manifesto → services → portfolio → method → testimonials → positioning → final CTA; empty catalog sections omitted; CTA → contact; preserve `data-testid="home-primary-cta"`
|
||||
- [x] 5.2 Rebuild home components/pages to match editorial composition (merge proof+cases into one portfolio block; add manifesto + positioning; four method steps)
|
||||
- [x] 5.3 Wire settings-driven copy and demo-image disclosure note; keep single `h1`
|
||||
- [x] 5.4 Run home feature tests
|
||||
|
||||
## 6. Internal public pages as chapters
|
||||
|
||||
- [x] 6.1 Extend/adjust public page feature tests for services, portfolio index/show, about, contact (presentation-only), privacy and branded errors under the new layout
|
||||
- [x] 6.2 Restyle `pages/services`, `pages/portfolio/*`, `pages/about`, `pages/contact`, `pages/privacy`, `errors/404`, `errors/500` to Heritage Editorial without changing route contracts or inventing proof
|
||||
- [x] 6.3 Confirm contact page shows settings channels and creates no leads
|
||||
- [x] 6.4 Run `PublicPagesTest` and related SEO/N+1 tests
|
||||
|
||||
## 7. Accessibility, browser and visual gates
|
||||
|
||||
- [x] 7.1 Update browser accessibility tests for brand mark name, keyboard path to primary CTA, mobile menu operability, axe on covered routes, reduced motion and clean console
|
||||
- [x] 7.2 Update `VisualContentSeeder` for deterministic Heritage Editorial content (SP + real testimonial subset + fixtures)
|
||||
- [x] 7.3 Run browser a11y/smoke suites; fix regressions
|
||||
- [x] 7.4 Run `composer visual:update` and review desktop `1440×1000` / mobile `390×844` diffs for home, services, portfolio, portfolio detail before committing baselines
|
||||
|
||||
## 8. Quality closeout
|
||||
|
||||
- [x] 8.1 Run `composer pint` and `composer phpstan` on touched PHP
|
||||
- [x] 8.2 Run `composer test:feature` and `composer test:browser`
|
||||
- [x] 8.3 Run `composer quality` (or equivalent full gate) and fix remaining failures
|
||||
- [x] 8.4 Update surface brief / note remaining unresolved items (official contacts, final testimonial authorization, authorized photography) without inventing facts
|
||||
Reference in New Issue
Block a user