Lição 9 de 9: Checklist do Módulo 4

Confira os 10 critérios do lançamento

Esta página é um checklist. Confere os 10 critérios que separam um lançamento bem feito de um deploy precário que vai dar trabalho daqui a 2 semanas. Você sai daqui sabendo se segue pro M5 ou se tem buraco pra fechar.

Mesma forma dos checklists anteriores (M1/L07, M2/L07, M3/L13): você cola dois prompts no Claude, ele lê seu repo e a produção, e responde OK/FAIL por item.

Como usar

Cada item tem 3 partes: o critério, um detalhe explicando por que importa, e um link de remediação pra lição que ensina como corrigir.

Pra marcar: clique em cada item conforme você confere. O estado fica salvo no navegador.

Pra conferir: dois prompts em batelada, 5 itens cada. O Claude lê os arquivos do seu projeto e responde item por item.

Prompts para a verificação

Cole os dois prompts abaixo no Claude, um de cada vez.

Vou usar a checklist do L09 do Módulo 4 do Builder OS. Leia o repo do projeto + estado de produção e confere os 5 primeiros itens. Para cada um, responde OK ou FAIL + 1 linha de motivo.

1. env-example-complete — Arquivo `.env.example` na raiz, listando todas as variáveis usadas no código? Compara `grep -rh "process.env." src/` com o conteúdo de `.env.example`. Cada variável usada deve aparecer (sem valor real).

2. build-green — `npm run build` passa local sem erros? Roda e mostra exit code.

3. production-deploy-live — Site rodando em produção? Pega o URL de `docs/decisions.md` (Domínio) ou `*.vercel.app` do `vercel ls` mais recente. Faz `curl -I <url>` e confirma 200 + SSL ativo.

4. doctor-six-green — `npm run doctor` (criado na L02) retorna 6 OKs? Roda e mostra o output.

5. analytics-real — Pelo menos 1 evento real chegando no dashboard do PostHog/Plausible? Procura no código por `posthog.capture` ou `plausible(` (não só `console.log`). Confirma que o SDK está carregado (script tag no HTML servido por prod).

E os 5 últimos:

Continue a verificação. Itens 6 a 10:

6. mcp-postgres-wired — `.mcp.example.json` no repo, com configuração de Postgres MCP? `.mcp.json` local existe? `.gitignore` esconde `.mcp.json` mas permite `.mcp.example.json`? Confere os 3.

7. first-report-saved — Existe pelo menos 1 arquivo em `docs/reports/<data>.md` gerado via MCP (ou script fallback)?

8. feature-flags-installed — `src/config/features.ts` (ou caminho equivalente) existe com 2+ flags? Pelo menos 1 flag é usada no código (`grep "FEATURES\." src/`)?

9. rollback-procedure-documented — `docs/runbook.md` existe com seções "Rollback de deploy" e "Kill switch"?

10. worktree-flow-documented — Skill `.claude/skills/worktree-flow/SKILL.md` (ou equivalente) existe? Se você não fez worktrees ainda, pode marcar OK desde que a skill esteja escrita (vai usar depois).

Para cada item: OK / FAIL + 1 linha de motivo.

Conforme Claude responder, marca os itens na checklist acima.

Decisão: você está pronto pro Módulo 5?

Quando um item falhar

Casos em que você pode adiar:

• Item 6 (MCP): se o MCP não conecta (firewall, versão), o fallback de script Node (scripts/db-report.ts) resolve o problema (geração de relatório sem psql). Marca como OK se o fallback está rodando.
• Item 10 (worktrees): skill instalada mas worktree nunca criado é OK pro M5. Você usa quando precisar.

Casos em que você não deve seguir:

• Itens 1-4 (env, build, deploy, doctor): infraestrutura crítica. Sem isto, M5 não tem chão.
• Item 5 (analytics): sem evento real chegando, você lança o M5 sem dado pra medir efeito. Não faz sentido.

Ship Wall — adiciona seu produto ao mural público

(Opcional, mas recomendado.) O Builder OS tem um Ship Wall que mostra produtos lançados pelos leitores. Adicionar o seu é um PR no repo builder-os com 5 campos: nome, URL, descrição em 1 frase, módulo de onde lançou, e GitHub do autor.

Cria um patch no fork do builder-os com seu produto adicionado ao `data/ships.json`. Estrutura:

{
"name": "<nome>",
"url": "<url-de-producao>",
"tagline": "<1 frase, pt-BR ou en — qual idioma público do produto>",
"shippedFromModule": 4, {/* voice-allow: R4 */}
"github": "<usuario-do-github>",
"shippedAt": "<data-ISO>" {/* voice-allow: R4 */}
}

Mostre o diff antes. Depois abre PR pra `jpvss/builder-os` (não merge — só abre; a curadoria é feita).

Aprove. Mesmo que o PR não seja mergeado de imediato (a curadoria é leve), o gesto público de listar te força a escrever a tagline, e escrever a tagline em 1 frase é um dos exercícios mais úteis pra fechar o M4.

Build Diary — o CEAP teve checklist de lançamento próprio

O CEAP tem LAUNCH_CHECKLIST.md com itens organizados por fase, não por módulo. Trecho da Phase 1:

Phase 1: Visão Geral - COMPLETED

Domain Setup

• Register escoladados.com at Cloudflare
• Configure DNS for subdomain

Code Preparation

• Feature flags created (src/config/features.ts)
• Production URLs updated in index.html

Verification

• Site loads at https://ceap.escoladados.com
• Only "Visão Geral" tab visible
• Test all charts load correctly

A diferença pra este checklist do M4 é o foco: o do CEAP é pós-deploy, pra verificar que subiu certo; este aqui é pré-Módulo-5, pra verificar que tem base pra construir os hábitos do Compor.

O princípio é o mesmo: não avançar sem evidência objetiva. O Módulo 5 (Compor) vai te pedir pra instalar hooks, automatizar e refinar, e essas operações exigem que a infraestrutura abaixo (deploy, analytics, MCP, flags) esteja sólida. Esse checklist confirma o solo.

Takeaways do M4

• Produção muda o ambiente (build, env vars, banco), não só a URL. Build local antes de qualquer deploy.
• Doctor + skill deploy-and-verify materializam o ritual pré-deploy em código + workflow.
• Domínio próprio é escolha registrada (docs/decisions.md), não default.
• Analytics real responde "X pessoas atravessam cada estágio". Funil definido no M2, instalado agora.
• MCP transforma o ciclo de descoberta: pergunta em pt-BR vira dado, sem psql.
• Feature flags + rollback = lançamento contínuo sem medo. 30 segundos pra desfazer.
• Worktree quebra a amarra do checkout único quando 2+ features rodam em paralelo.

Você terminou quando

Marcou 8+ dos 10 itens e tem clareza sobre o que ainda precisa fechar (se algo).