launch-checklist

O que launch-checklist faz?

Execute a auditoria automatizada, corrija no código o que falhar, reexecute até ficar limpo e então passe pelos itens manuais que o script não consegue ver. Reporte ao usuário o que você alterou e o que ainda precisa ser feito por ele.

Passo 1 — Executar a auditoria

Contra a URL de produção, se existir; caso contrário, contra uma build de produção local (npm run build && npm start, não o servidor de desenvolvimento — servidores dev adicionam scripts e ignoram cache):

python3 scripts/audit_site.py https://example.com            # relatório em texto
python3 scripts/audit_site.py http://localhost:3000 --max-pages 30 --json > audit.json

O que é verificado (detalhes em references/checks.md):

• Por página: <title> (10–60 caracteres), meta description (50–160), exatamente um <h1>, <html lang>, viewport, canonical (absoluto, mesmo host), og:title/description/image, twitter:card, <img> sem alt, tamanho do HTML, tempo de resposta, noindex em páginas que provavelmente você quer indexadas, títulos/descrições duplicados entre páginas.
• Site: /robots.txt existe e não contém Disallow: / para tudo, referencia um sitemap; /sitemap.xml (ou aquele nomeado no robots) é interpretado e suas URLs retornam 200 no mesmo host; favicon acessível; apple-touch-icon; uma URL aleatória retorna 404 (não 200 ou redirecionamento para home); redirecionamento http→https (para sites https); links para política de privacidade / termos (e política de reembolso se o site vende algo); presença de /llms.txt (apenas informativo).

Código de saída 1 quando houver qualquer FAIL. Páginas rastreadas: URL inicial + links do mesmo host, até --max-pages (padrão 20).

Passo 2 — Corrigir no código

Detecte o framework e use a receita correspondente. Para Next.js App Router, references/fixes-nextjs.md contém robots.ts, sitemap.ts, not-found.tsx, metadata, convenções de ícones prontos para uso. Para HTML genérico/outros frameworks: references/fixes-generic.md.

Regras:

• Corrija a causa raiz (layout compartilhado / helper de metadados), não página por página, quando o problema se repetir.
• Nunca adicione noindex ou bloqueie rastreadores sem perguntar.
• Páginas legais ausentes: gere-as com a skill legal-pages se instalada; caso contrário, avise o usuário — não invente texto legal diretamente.
• Imagens OG ausentes: use a skill og-image-kit se instalada.

Passo 3 — Reexecutar até não haver FAIL

Reexecute o mesmo comando. Itens WARN: corrija os baratos e liste o restante para o usuário.

Passo 4 — Itens manuais (o script não consegue verificar)

Percorra references/manual-checklist.md com o usuário — analytics instalado, rastreamento de erros, entregabilidade de e-mail transacional (SPF/DKIM/DMARC), fluxo de pagamento testado de ponta a ponta com um pequeno pagamento real, backups, monitor de uptime, verificação no Search Console / Bing Webmaster e envio de sitemap, status da renovação do domínio. Marque cada um como feito / não aplicável / o usuário fará.

Passo 4b — Auto-check de pagamento (se o site recebe dinheiro)

python3 scripts/payment_check.py --src . --provider creem          # varredura de código
python3 scripts/payment_check.py --url http://localhost:3000        # sonda uma build em execução
python3 scripts/payment_check.py --url http://localhost:3000 --secret "$CREEM_WEBHOOK_SECRET"  # apenas secret de modo de teste

FAILs: webhook aceita requisições não assinadas ou forjadas, analisa JSON antes de verificar, sem desduplicação por id de evento, página de sucesso concede acesso, segredos de pagamento em NEXT_PUBLIC_* ou commitados, webhook redireciona ou está atrás de um desafio de bot. Corrija-os, reexecute e depois faça os testes manuais com cartão em references/payment-checks.md (cartão de sucesso, cartão recusado, reembolso, reenvio pelo dashboard, cancelamento). Nunca passe um secret de webhook de produção. scripts/test_payment_check.py é o teste do próprio script. Arquivos de teste, spec e fixture (*.test.ts, *.spec.tsx, test_*.py, qualquer coisa em tests/, e2e/, __tests__/, fixtures/) não são julgados como handlers ou páginas de sucesso, porque propositalmente enviam requisições não assinadas e inserem linhas; eles ainda são verificados quanto a chaves de produção commitadas. O relatório diz quantos foram ignorados (INFO test files).

Formato do relatório

Auditoria de lançamento para <url> — <data>
FAIL corrigido: …   (arquivo:linha alterado)
WARN corrigido: …
Ainda em aberto (precisa de você): …
Checklist manual: x/y concluídos