Selzler Construtora

##o_problema

O site atual é WordPress estático. Cada obra concluída, cada cliente novo no portfólio, exigia acionar um desenvolvedor. Os sócios não tinham como publicar o próprio trabalho.

##o_que_faz

• Frontend público replicando a arquitetura de informação existente: home, sobre, obras concluídas separadas em pública/industrial/residencial, obras em andamento, clientes, contato e política de privacidade.
• Painel admin atrás de login dos sócios, sem cadastro público. Usuários são criados por seed. CRUD completo de obras e clientes, com upload de imagem.
• Carousel de logos de clientes em marquee contínuo estilo JetBrains, com logos reais.
• Card de consentimento de cookies com gate de analytics, para LGPD.
• Integração com Google Places para avaliações, sincronizada em background por hosted service.
• Warm-up do container na página de contato, detalhe de cold start serverless resolvido antes de o visitante sentir.

##stack

##medido

Commits em dez dias

119histórico git, 14/07/2026 a 24/07/2026

Achados de auditoria fechados

12docs/audit/2026-07, quatro varreduras separadas

##como_foi_construido

Este é o repositório onde a metodologia fica mais explícita. A stack foi travada por decisão datada ("travada em 14/07/2026, não trocar sem discussão explícita") e a estrutura, auth e padrões de teste foram deliberadamente herdados do Telas Paraná. Reuso entre projetos do mesmo autor, não reinvenção. A escolha do monolito modular também é justificada e não copiada: sem split de processo até haver razão concreta.

A configuração de agentes carrega uma equipe de suboperadores especializados (architect, backend, frontend, DBA, devops, cybersec, DPO, QA, conteúdo e vault), cada um com memória persistente própria guardando lições concretas do projeto. Essas memórias são correções de comportamento que sobreviveram à sessão que as gerou.

O trabalho é organizado em PRDs numeradas (carousel de clientes, auth JWT, login no frontend, uma vulnerabilidade de OpenAPI, hardening do admin) mais uma auditoria formal com quatro varreduras separadas em backend, banco, frontend e segurança, cujos doze achados foram fechados em commit próprio.

Incomum num projeto deste porte: uma pasta jurídica analisando Lei do Software, Código Civil, LGPD e Marco Civil, um mapa de subprocessadores de dados, um DPA assinado versionado em PDF, e uma auditoria das afirmações públicas do site para nenhum número publicado ser inventado.

##limitacoes_conhecidas

• Sem deploy. Tudo até a v0.4 está completo e funcionando localmente, mas a v1.0, deploy em produção com domínio próprio, continua aberta, então é apresentado como funcional e não como em produção.
• A suíte de testes do frontend cobre invariantes estruturais, não aparência. Layout e acessibilidade ainda exigem medição direta em navegador real.
• Há uma próxima sprint desenhada que existe só no papel: RAG vetorial local sobre a documentação, exposto aos agentes por servidor MCP.

##roadmap

• v0.1 health check ✓
• v0.2 CRUD ✓
• v0.3 frontend público ✓
• v0.4 auth admin ✓
• v1.0 deploy em produção com domínio próprio: pendente

##tempo de código rastreado

19 hrs 17 mins Fonte: WakaTime · rastreado desde 2026-03-17 até agora