Kerno Framework

FASE 1 Configuração Inicial Antes do primeiro prompt

Prepare o ambiente antes de escrever qualquer código. Esta fase garante que todo projeto Lovable já nasce com documentação, segurança e governança.

📋 1.1 Preparar o PRD_SYSTEM.md

Escreva o documento de requisitos do produto. Inclua:

Visão geral do produto (o que faz, para quem)
Lista de funcionalidades desejadas
Tipo de dados que manipula (usuários, financeiro, saúde, etc.)
Integrações necessárias (Stripe, APIs externas, etc.)
Requisitos de segurança específicos
Preferências técnicas (se houver)

PRD_SYSTEM.md — você cria este arquivo

📐 1.2 Configurar o KERNO-DOCS.md

Use o arquivo padrão do Kerno Framework. Ele define os 15 documentos que o Lovable vai criar e manter automaticamente. Não precisa modificar — funciona como está.

KERNO-DOCS.md — arquivo padrão do framework

⚙️ 1.3 Configurar o Lovable

Cole o System Prompt nas configurações do Lovable (Custom Instructions):

LOVABLE-SYSTEM-PROMPT.md — copie a seção "Prompt para colar"

Onde colar: Lovable → Configurações (⚙️) → Custom Instructions ou System Prompt

🚀 1.4 Primeiro prompt no Lovable

Envie os 2 arquivos e use o prompt de inicialização:

Upload: PRD_SYSTEM.md + KERNO-DOCS.md
Cole o prompt de primeiro envio (do LOVABLE-SYSTEM-PROMPT.md)
O Lovable vai criar os 15 docs + PRD_SYSTEM_MILESTONES.md + implementar Milestone 1

🔗 1.5 Conectar ao GitHub

No Lovable, conecte ao GitHub se ainda não estiver:

Lovable → Settings → GitHub → Connect
Repositório privado (dados sensíveis)
Branch principal: main

FASE 2 Desenvolvimento Durante o ciclo de prompts

Desenvolva milestone por milestone. O Lovable mantém a documentação automaticamente graças ao System Prompt.

🔄 2.1 Ciclo de desenvolvimento

Para cada sessão de trabalho:

Abra o Lovable
Use o prompt de retomada (com pendências da sessão anterior)
Desenvolva as features da milestone atual
O Lovable atualiza docs automaticamente a cada resposta
Ao terminar, use o prompt de fechamento de sessão

📊 2.2 Controle de milestones

Ao concluir cada milestone:

Use o prompt de fechamento de milestone
Revise o DELIVERY_REPORT.md gerado
Confirme que tudo do escopo foi entregue
Inicie a próxima milestone

✅ 2.3 QA durante desenvolvimento

O QA_PLAN.md é atualizado a cada feature. Use-o para testar manualmente:

Abra a aplicação no preview do Lovable
Siga os cenários de teste listados no QA_PLAN.md
Teste em mobile (redimensione o navegador)
Reporte bugs ao Lovable com descrição clara

FASE 3 Segurança — SAST & DAST Após primeira milestone funcional

SAST (Static Application Security Testing) analisa o código sem executar. DAST (Dynamic Application Security Testing) testa a aplicação rodando. Vamos configurar ambos.

🔍 3.1 SAST — Configurar no GitHub

Crie o arquivo .github/workflows/security-audit.yml no GitHub:

GitHub → seu repo → Add file → Create new file
Nome: .github/workflows/security-audit.yml
Cole o conteúdo do security-audit-v2.yml do Kerno

O que roda automaticamente (SAST):

Ferramenta	O que verifica	Origem
Semgrep	OWASP Top 10, XSS, SQL Injection, React, TypeScript, Secrets	Awesome AI Security list
npm audit	Vulnerabilidades em dependências (CVEs)	npm nativo
Scanner Lovable	service_role, RLS, auth, localStorage, error handling	Scanner customizado Kerno

📦 3.2 Dependabot — Monitoramento de dependências

Crie .github/dependabot.yml:

.github/dependabot.yml

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
    open-pull-requests-limit: 5
    labels:
      - "security"
      - "dependencies"

🔐 3.3 GitHub — Configurações de segurança

No repositório GitHub, vá em Settings → Security:

Configuração	Onde	Ação
Secret scanning	Settings → Code security	Ativar "Secret scanning"
Push protection	Settings → Code security	Ativar "Push protection" (bloqueia push com secrets)
Dependabot alerts	Settings → Code security	Ativar alertas automáticos
Dependabot security updates	Settings → Code security	Ativar PRs automáticos
Branch protection	Settings → Branches	Proteger main: exigir reviews e status checks

🗄️ 3.4 Supabase — Verificação manual (DAST parcial)

O scanner não acessa o banco. Faça manualmente no painel do Supabase:

Verificação	Onde no Supabase	⬜
RLS ativo em TODAS as tabelas	Table Editor → cada tabela → Policies	⬜
Cada tabela tem policies para SELECT/INSERT/UPDATE/DELETE	Table Editor → Policies	⬜
Storage buckets sensíveis são privados	Storage → cada bucket	⬜
Email confirmation ativo	Auth → Settings	⬜
Rate limiting configurado	Auth → Rate Limits	⬜
MFA habilitado (se dados sensíveis)	Auth → Settings → MFA	⬜

⚠️ Esta é a verificação mais crítica do pipeline. RLS desativado = todos os dados expostos.

🌐 3.5 DAST — Testes dinâmicos básicos

Com a aplicação no preview do Lovable ou Vercel, teste manualmente:

Teste	Como fazer	⬜
Acesso sem login	Abra URLs protegidas diretamente. Deve redirecionar para login.	⬜
Acesso a dados de outro usuário	Mude IDs na URL. Não deve mostrar dados alheios.	⬜
XSS em campos de texto	Digite `<script>alert(1)</script>` em campos. Não deve executar.	⬜
Console limpo	Abra DevTools → Console. Não deve mostrar dados sensíveis.	⬜
Network limpo	DevTools → Network. Verifique que não envia dados desnecessários.	⬜

FASE 4 Deploy & Hardening Quando o produto estiver pronto para produção

▲ 4.1 Vercel — Deploy seguro

Configurações obrigatórias na Vercel:

Configuração	Onde	Valor
Environment Variables	Settings → Environment Variables	Adicione VITE_SUPABASE_URL e VITE_SUPABASE_ANON_KEY (apenas Production)
Preview deployments	Settings → General	Proteger com senha (evitar acesso a previews com dados reais)
Authentication	Settings → Deployment Protection	Ativar "Vercel Authentication" para previews
Build & Output	Settings → General	Framework: Vite. Build command: npm run build

Headers de segurança — crie vercel.json na raiz:

vercel.json

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "X-XSS-Protection", "value": "1; mode=block" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Permissions-Policy",
          "value": "camera=(), microphone=(), geolocation=()" },
        { "key": "Strict-Transport-Security",
          "value": "max-age=63072000; includeSubDomains; preload" },
        { "key": "Content-Security-Policy",
          "value": "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://*.supabase.co wss://*.supabase.co; font-src 'self' https://fonts.gstatic.com; frame-ancestors 'none'" }
      ]
    }
  ]
}

☁️ 4.2 Cloudflare — CDN + Proteção DDoS

Configuração recomendada (adicional, não obrigatória no início):

Passo	O que fazer
1. Criar conta	cloudflare.com → Free plan é suficiente
2. Adicionar domínio	Sites → Add a site → seu domínio
3. Mudar nameservers	No registrador do domínio, apontar para os NS do Cloudflare
4. SSL/TLS	SSL/TLS → Full (strict)
5. Always Use HTTPS	SSL/TLS → Edge Certificates → Always Use HTTPS: ON
6. HSTS	SSL/TLS → Edge Certificates → HSTS: Enable
7. Bot Fight Mode	Security → Bots → Bot Fight Mode: ON
8. Security Level	Security → Settings → Security Level: Medium
9. WAF Rules	Security → WAF → Managed Rules: ON (OWASP Core Ruleset)

💡 Cloudflare Free já inclui: CDN global, proteção DDoS, SSL automático e WAF básico. É uma camada significativa de segurança sem custo.

🔐 4.3 Domínio customizado + SSL

Na Vercel:

Settings → Domains → Add → seu domínio
Se usando Cloudflare: apontar CNAME para cname.vercel-dns.com
SSL é automático (tanto Vercel quanto Cloudflare)
Aguardar propagação DNS (até 48h, geralmente minutos)

🗄️ 4.4 Supabase — Configuração de produção

Configuração	Onde
Desativar confirmação de email em dev → Ativar em prod	Auth → Settings
Configurar domínio customizado de email	Auth → Email Templates
Configurar Site URL para produção	Auth → URL Configuration
Adicionar Redirect URLs permitidas	Auth → URL Configuration
Ativar Point-in-Time Recovery (backups)	Database → Backups
Configurar Rate Limiting	Auth → Rate Limits

FASE 5 Monitoramento Contínuo Pós-deploy, permanente

Após o deploy, mantenha o projeto seguro e saudável com monitoramento contínuo.

🤖 5.1 Automático — já configurado

O que	Frequência	Onde
Semgrep + npm audit + Scanner	A cada push	GitHub Actions
Dependabot	Semanal	GitHub
Secret scanning	Contínuo	GitHub
Push protection	A cada push	GitHub

👀 5.2 Manual — agenda de revisão

Frequência	O que revisar
Semanal	Verificar aba Actions no GitHub (❌ ou ✅). Baixar relatórios se houver falhas.
Mensal	Rodar `npm audit` manualmente. Verificar logs no Supabase. Revisar novas tabelas/policies.
Trimestral	Revisar todas as RLS policies. Rotacionar chaves de API. Atualizar SECURITY_REPORT.md.
A cada novo cliente/projeto	Usar o Kerno Framework desde o início. Todos os passos deste roadmap.

🔮 5.3 Fase futura — quando escalar

Ferramentas para adicionar quando o básico estiver maduro:

Ferramenta	Para quê	Quando
Safe Zone	Detecção de PII (dados pessoais) em tempo real	Quando tiver dados reais de saúde em produção
Claude Code Security Review	Análise de código com IA a cada PR	Quando quiser mais profundidade na análise
Cloudflare WAF Rules	Firewall de aplicação web avançado	Quando tiver tráfego significativo
Sentry / LogRocket	Monitoramento de erros em produção	Quando tiver usuários ativos

Arquivo	Tipo	Quando usar
`KERNO-DOCS.md`	Upload no Lovable	Todo projeto — define os 15 docs obrigatórios
`LOVABLE-SYSTEM-PROMPT.md`	Custom Instructions do Lovable	Todo projeto — governa comportamento do Lovable
`PRD_SYSTEM.md`	Upload no Lovable	Todo projeto — você cria para cada projeto
`SECURITY.md`	Base para SECURITY_RULES.md	Todo projeto — regras de segurança
`security-audit-v2.yml`	GitHub Actions	Todo projeto — pipeline SAST automático
`dependabot.yml`	GitHub	Todo projeto — monitoramento de dependências
`vercel.json`	Raiz do projeto	Todo projeto com Vercel — headers de segurança

📁 Arquivos do Kerno Framework