Manoel Freitas
63c0269489
* feat: aplicar identidade Heritage Editorial ao painel Filament O painel admin ainda usava os defaults de fábrica do Filament (Amber, Zinc, Inter Variable, dark mode ligado) enquanto o site público já seguia o design system Heritage Editorial há várias entregas — a inconsistência ficava evidente para quem navegava entre as duas áreas e não havia nenhum teste travando a configuração do painel. - Cores primary/gray/danger/warning/success viram arrays explícitos de 11 tons (não Color::hex()/string), a única forma de preservar os hexadecimais exatos do DESIGN.md — Color::hex() decompõe a cor e remonta lightness/chroma por uma tabela fixa, perdendo a cor real. Os tons foram escolhidos verificando empiricamente com ButtonComponentColorMap qual shade o botão sólido realmente usa (600/500/50), e o tom 50 do primary é um verde-oliva claro (não branco puro) porque BadgeComponent usa bg-color-50 diretamente e um branco puro tornaria o badge quase invisível sobre o Papel Marfim. - EB Garamond self-hosted via LocalFontProvider (sans/mono/serif), sem reintroduzir uma requisição externa ao fonts.bunny.net — o hook HEAD_END reaproveita o mesmo <x-fonts /> do site público. - Novo tema Vite (resources/css/filament/admin/theme.css) zera radius e shadow só no escopo do Filament, incluindo a variável --radius "bare" (usada em ~227 regras do próprio Filament) e um override manual para o CSS pré-compilado do tooltip Tippy.js, que não é alcançado pelo @theme. - Dark mode desativado: o Heritage Editorial é uma paleta única. - Teste de regressão (AdminPanelBrandParityTest) pinando cores, fontes e configuração do tema, incluindo uma renderização real de /admin/login — foi essa renderização que pegou um bug real: passar a família já entre aspas simples quebrava a declaração CSS (--font-family: ''EB Garamond''), silenciosamente caindo para ui-sans-serif. Bundle público verificado byte a byte: nenhuma declaração CSS existente mudou de valor (apenas classes novas e não usadas pelo site público foram adicionadas ao app.css, um efeito colateral inerte de ter uma segunda entrada Tailwind no mesmo build do Vite). Co-Authored-By: Claude noreply@anthropic.com AI-Assisted: yes AI-Tool: claude-code * fix(build): copiar CSS do Filament no estágio frontend e neutralizar sombras Dois defeitos encontrados ao revisar a paridade visual do painel. O primeiro impedia o build da imagem. O `resources/css/filament/admin/ theme.css` importa o CSS não compilado do próprio Filament, e o estágio `frontend` do Dockerfile copia apenas `package.json`, `vite.config.js`, `resources` e `public` — nunca `vendor`. O `npm run build` falhava na resolução do import, o que derrubaria os jobs `container` e `browser` do CI. Agora a subárvore `vendor/filament` é copiada do estágio do composer, em vez de todo o `vendor`, para manter o contexto pequeno. O segundo é silencioso e mais interessante. O plugin do Tailwind compartilha um único contexto entre todas as entradas do build, então o `@source app/Filament/**` da entrada do painel torna visível o uso de `shadow-*` do Filament e o Tailwind passa a emitir seus valores padrão de `--shadow-sm/md/lg` também no bundle público. Verificado por diff do `app.css` construído com e sem a entrada do tema. Nada no site público usa utilitário de sombra hoje, então a renderização não muda e os baselines visuais seguem válidos. Mas deixar valores reais de sombra definidos no CSS que vai para produção permitiria que um `shadow-sm` futuro em elemento público violasse a Tonal Layer Rule do DESIGN.md em silêncio — e o HeritageEditorialTokensTest só inspeciona arquivos de origem, então não pegaria. Os tokens de sombra passam a ser fixados em transparente no `@theme` do `app.css`, com teste que falha se algum deixar de ser. A regra continua verdadeira no artefato que realmente ship. Co-Authored-By: Claude noreply@anthropic.com AI-Assisted: yes AI-Tool: claude-code --------- Co-authored-by: manoel.neto <manoel.neto@creditas.com>
8.9 KiB
8.9 KiB