Lição 13 de 13: Checklist do Módulo 3

Confira a fatia 1 com evidência

Confere os 8 critérios que separam uma fatia 1 funcionando ponta a ponta de uma que vai deixar buracos no Módulo 4 (Lançar). Você sai com clareza: "tudo OK, sigo pro M4" OU "tem buraco X, volto na lição Y."

Mesmo formato do checklist da L10 do Módulo 1 e da L07 do Módulo 2: você cola dois prompts no Claude (4 itens cada), ele lê seu repo e responde OK/FAIL para cada item, e você marca abaixo.

Como usar

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

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

Como conferir: dois prompts em batelada (4 itens cada). 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 L13 do Módulo 3 do Builder OS. Leia o repo do projeto e confira os 4 primeiros itens. Para cada um, responda OK ou FAIL + 1 linha de motivo.

1. schema-table-exists — A tabela principal da fatia 1 existe no banco local? Comando depende do stack:
 - Drizzle + Postgres: `drizzle-kit introspect`, ou `psql -d <db> -c "\dt"`
 - Drizzle + SQLite: `drizzle-kit introspect`, ou `sqlite3 <arquivo.db> ".tables"`
 - Prisma: `npx prisma studio` (UI) ou `npx prisma db pull` (sincroniza schema)
 - Outro ORM: comando equivalente.
 A tabela deve existir e ter as colunas que estão no arquivo de schema.

2. zod-validation-at-boundary — Existe um Zod schema sendo usado em pelo menos uma API route com .refine() para validação custom (CPF/CNPJ ou outro)? Procura por importação de zod nas API routes e por chamadas de safeParse ou parse com schemas que usam .refine.

3. api-route-201-409 — A API route principal retorna 201 no caminho feliz e 409 em duplicata? Procura no código por status 201 e 409 explícitos. Se há try/catch ao redor de insert e tratamento de unique constraint, mais sinal.

4. form-four-states — O formulário da fatia 1 tem 4 estados nomeados (idle/submitting/success/error)? Procura por useState com type union de strings (não boolean isLoading).

E os 4 últimos:

Continue a verificação da checklist. Itens 5 a 8:

5. one-event-tracked — Existe pelo menos uma chamada `analytics.track(...)` no código, em um ponto de sucesso (ex: imediatamente antes de retornar 201)? Procura por arquivo `lib/analytics.ts` (ou equivalente) e por `docs/analytics.md`.

6. lessons-learned-written — Existe arquivo `docs/lessons-learned.md` no repo, com 3+ notas honestas (não vazias, não 1 frase só)?

7. no-premature-skills — A pasta `.claude/skills/` tem skill nova além das que vieram do starter? Lista as skills. Critério:
 - 0 skills novas + `docs/maybe-skills.md` existe: OK.
 - 1 skill nova com 3ª-repetição documentada (commit/comentário citando o caso real): OK — passou a regra da L11.
 - 2+ skills novas, ou 1 sem justificativa documentada: FAIL.
 As canônicas que já vêm do Starter (commit-and-pr, getting-started, nextjs-react, plan-then-work, ui-design) não contam.

8. stuck-mode-playbook — Existe arquivo `docs/stuck-mode-playbook.md` no repo com os 3 padrões (proposta confusa / refazendo sem parar / pulando tarefa)?

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

Conforme o Claude for respondendo, marque os itens na checklist acima.

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

Quando um item falhar

Casos em que você pode adiar:

• Item 6 (lessons-learned): se você só fez a fatia 1 em uma sessão curta, talvez não tenha 3 notas substanciais ainda. OK adicionar mais nas próximas semanas.
• Item 7 (stuck-mode-playbook): se o /work nunca travou na sua fatia 1, escrever o playbook fica abstrato. OK voltar depois da primeira vez que travar.

Casos em que você não deve seguir:

• Itens 1 a 4 (schema, Zod, API, form): são a infraestrutura da fatia 1. Se algum falha, o Módulo 4 vai tentar fazer deploy de um produto quebrado.
• Item 5 (evento rastreado): sem isso, no Módulo 4 você não sabe se alguém usou.

Build Diary — o CEAP também tinha checklist antes do lançamento

O CEAP tem um LAUNCH_CHECKLIST.md com itens estruturados em fases (Phase 1 / Phase 2 / etc.). A diferença pra este checklist do M3 é o foco: o do CEAP é pré-deploy (subir certo); este aqui é pré-deploy interno (rodar local certo, antes de pensar em deploy).

O princípio é o mesmo: não avançar sem verificação concreta. O Módulo 4 tem seu próprio checklist final, que cobre Vercel deploy, custom domain, analytics em produção e MCP plugado. Este aqui garante que a fatia 1 está pronta pra subir.

Takeaways do M3

• Aprovar tarefa por tarefa (e não o plano inteiro de uma vez) faz você saber onde algo quebrou quando quebra.
• A borda blindada com Zod + .refine concentra a validação na entrada. O erro estoura onde o dado chega, sem try/catch defensivo espalhado pelo código.
• Schema é decisão de produto. Tipos brasileiros (CPF varchar(11), valor em centavos bigint) decididos agora poupam horas de refactor depois.
• Estados nomeados ('idle' | 'submitting' | 'success' | 'error') cobrem 4 cenários com 4 UIs. Um boolean isLoading esconde os outros dois.
• Um evento rastreado agora já prova o caminho feliz; os outros 3 do funil vêm no Módulo 4. wedge_consumed no sucesso, e nunca PII nas propriedades (LGPD by design).
• Regra da 3ª repetição: skill só na 3ª aparição. Antes disso, docs/maybe-skills.md. Skills prematuras viram entulho.
• Playbook do travamento commitado: quando o /work emperra, você diagnostica por segmento (proposta / loop / pulo de tarefa) sem reler a sessão inteira.

Você terminou quando

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