Elquer Carlos

Landing page do Kmarote: portabilidade, preview local e a briga com a CSP

Construção da LP do Kmarote do zero: arquitetura isolada, preview via Apache/XAMPP, feedback de UX e resolução de bloqueio por Content Security Policy.

O dia foi inteiro numa frente só: construir a landing page do Kmarote. Não é uma tela qualquer — é a principal porta de entrada de cliente novo. Cada decisão aqui pesa mais do que no resto do sistema.

Arquitetura antes do layout

O ponto de partida veio de uma exigência que eu já tinha documentado no briefing: a LP precisava viver fora da pasta ADMIN, numa pasta LP/ autocontida. A razão é objetiva — o domínio da LP vai rodar num servidor diferente do app principal. Qualquer dependência cruzada quebra no deploy.

A estrutura ficou assim:

LP/
├── index.php
└── assets/
    ├── css/styles.css
    └── js/main.js

Junto com isso, cobrei desde o briefing um detalhe que é fácil de esquecer: os botões “Começar” e “Entrar” precisam capturar qualquer parâmetro que chegue via GET e repassar pro app. Sem isso, campanha com UTM ou link de indicação perde o rastro exatamente no momento que o cliente clica — o ponto de maior custo de aquisição.

Preview local antes de julgar

Avaliar LP lendo HTML é inviável. Pedi um jeito de ver a página rodando de verdade e o Claude Code configurou um vhost no Apache do XAMPP apontando pra pasta LP/ (host interno). A partir daí a sessão passou a usar screenshots automatizados pra inspecionar o resultado a cada mudança, em vez de depender da minha memória visual de como o HTML se traduz no browser.

”Parece estranha e pouco profissional”

A primeira leva de versões não passou no crivo visual. Fui direto: em todas as versões a LP parecia estranha e amadora. Mandei usar a skill de UI/UX pra trazer a tela pro padrão de mercado, com usabilidade em primeiro lugar.

Numa tela de aquisição, erro de layout não é débito técnico — é cliente perdido. A conversa saiu do modo “fazer funcionar” e foi pro modo “refinar visual”. Iterações visuais, não lógica nova.

A briga com a CSP

O bloqueio técnico do dia apareceu no console do browser: estilos inline esbarrando na Content Security Policy configurada no servidor.

A política existente era:

style-src 'self' https://fonts.googleapis.com

Cada style= direto no elemento HTML era barrado. O caminho foi tirar todos os inline styles e mover tudo pro assets/css/styles.css, respeitando a CSP sem precisar enfraquecer a política com unsafe-inline.

Ficou registrada uma observação importante: esse erro só aparece quando a página é servida via HTTP de verdade — abrindo o arquivo diretamente no browser não aciona a CSP, então o bug fica invisível sem o vhost.

Estado ao fim do dia

Nenhum commit novo no repositório do Kmarote. A LP segue em construção local — o visual ainda não fechou. O trabalho de hoje ficou na máquina.

Pendências abertas:

  • Fechar o layout visual da LP
  • Validar comportamento dos parâmetros GET nos dois CTAs
  • Deploy teste no servidor separado pra confirmar que o isolamento funciona na prática

Estatísticas do dia:

Atividade no PC (ActivityWatch):

  • Tempo ativo: 2h 32min na janela monitorada

Por categoria:

  • Browsing: 56min
  • Coding: 34min
  • Uncategorized: 31min
  • AI Chat: 23min
  • Communication: 8min

Top apps: chrome.exe (1h 38min) · Antigravity IDE (34min) · WhatsApp (10min)

Top sites navegados: facebook.com (8min) · host interno da LP (7min) · chatgpt.com (4min) · claude.ai (2min) · youtube.com (2min)

Trabalho com IA:

  • Conversas claude.ai: 0
  • Sessões Claude Code: 1 (kmaroteApp)

Código produzido:

  • Commits: 0 (kmaroteApp) · 0 (Larissa)
Fim do ato