Lição 8 de 8: Checklist do Módulo 2

Esta lição confere os 8 critérios que separam um Módulo 2 fechado de um que vai gerar problemas na primeira semana de implementação no Módulo 3. Você não escreve nada novo aqui: só audita os 3 documentos que já produziu. É a mesma forma do checklist da L10 do Módulo 1, mas agora o que você confere é alinhamento de produto, não setup técnico.

Você cola dois prompts no Claude (4 itens cada), Claude lê os 3 documentos que você produziu (docs/product.md, docs/roadmap.md, e o feat-<nome>.md da fatia 1) e responde OK/FAIL para cada item.

Como usar a checklist

Cada item abaixo tem 3 partes: o critério, um detalhe explicando por que importa e (na maioria) um link para a 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) que você cola no Claude. Ele lê os 3 documentos e responde OK ou FAIL para cada item.

Prompts para a verificação

Cole os dois prompts abaixo no Claude, um de cada vez. Claude lê os 3 documentos e responde item por item.

Vou usar a checklist da L08 do Módulo 2 do Builder OS. Leia estes 3 arquivos:

1. `docs/product.md`
2. `docs/roadmap.md`
3. O arquivo de plano da fatia 1 (procure em `plans/` o arquivo que começa com `feat-`)

Depois confira os 4 primeiros itens e responda com OK / FAIL para cada um, com 1 linha explicando o porquê:

1. **product-md-four-sections** — `docs/product.md` tem as 4 seções (Problema, Usuário, Wedge, Não-objetivos) preenchidas, sem `<!-- TODO -->` sobrando.

2. **wedge-triangle-visible** — A seção Wedge do `docs/product.md` tem o triângulo visível (`usuário × tarefa × canal`)? Aplique o teste de troca: para cada um dos três, proponha uma troca razoável e me diga se a frase ainda faria sentido. Se algum elemento passar no teste de troca, FAIL.

3. **roadmap-three-vertical-slices** — `docs/roadmap.md` tem 3 fatias? Cada fatia tem entrega que funciona ponta a ponta (não "modelo de dados," não "API")? Aplique o teste do valor isolado: se a fatia 1 fosse o último entregável, ela ainda seria útil para alguém? Se sim, OK; se "depende da fatia 2," FAIL.

4. **plan-file-sharp-name** — O nome do arquivo `feat-<slug>` em `plans/` responde pelo menos 2 das 3 perguntas: entrada exata, saída exata, edge case brasileiro? Não é `feat-add-feature` ou `feat-implement-X`?

E os 4 últimos:

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

5. **plan-out-of-scope-three-plus** — A seção Out of scope do plano da fatia 1 tem 3 ou mais itens concretos (não está vazia, não tem itens vagos como "queremos manter simples")?

6. **plan-acceptance-verifiable** — Cada item de Acceptance criteria do plano é uma asserção sim/não (verificável)? Pelo menos 1 critério tem número (performance, tamanho, latência)? Marque FAIL se algum critério é "funciona corretamente," "performance boa," ou similar.

7. **acquisition-channel-specific** — A seção Wedge do `docs/product.md` (ou outra seção do mesmo arquivo) descreve um canal de aquisição específico — não "marketing digital," não "redes sociais"? Bonus: existe menção a 3 ou mais pessoas/contatos reais em algum lugar dos documentos?

8. **mod2-commits-conventional** — Rode `git log --oneline -15` e me diga se os commits do Módulo 2 (mensagens tipo `docs(product):`, `docs(roadmap):`, `docs(plans):`, `chore(plans):`) seguem Conventional Commits. FAIL se algum tem mensagem genérica (`update`, `wip`, `changes`).

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

Conforme Claude responder, marque os itens correspondentes na checklist acima.

Decisão: você está pronto para o Módulo 3?

A regra de decisão depende do número de itens marcados:

Quando um item falhar

Falhar em algum item não é problema. A função do checklist é justamente capturar essas falhas antes que elas se tornem dívida.

Casos em que você pode deixar para depois:

• Item 8 (commits Conventional Commits): se você já fez commits com mensagens informais, não vale fazer rebase só para arrumar. Anote como conhecido e use o padrão daqui para frente.

Casos em que você não deve seguir antes de corrigir:

• Itens 1 a 5 (produto, wedge, roadmap, nome do plano, Out of scope): se algum deles está vago, o Módulo 3 vai propagar essa vagueza para dentro do código. Volte à lição correspondente.
• Item 6 (Acceptance verificáveis): se os critérios não são verificáveis, no Módulo 3 você não vai conseguir saber quando a fatia 1 terminou.
• Item 7 (canal específico): se está vazio ou genérico, no Módulo 4 você termina o produto sem ter para quem mandar. Resolva agora.

Reuso desta checklist

Igual ao checklist da L10 do Módulo 1: ele é compartilhado entre projetos. Quando você usar o Builder OS para começar um produto novo, abra esta página de novo, marque tudo do zero, repita o ciclo. Os 8 itens são genéricos o suficiente para valer para qualquer wedge.

Os módulos 3, 4 e 5 vão ter checklists próprias, com o mesmo formato. Cada uma confere que o módulo anterior fechou bem antes do próximo começar.

Build Diary — checklist no projeto do CEAP

O CEAP tem seu próprio checklist no repositório, em um arquivo chamado LAUNCH_CHECKLIST.md. Não é o mesmo checklist desta lição (este aqui é de alinhamento de produto antes de construir; o do CEAP é de coisas a verificar antes de publicar uma feature em produção). Mas a lógica é a mesma: antes de seguir, conferir.

A função do checklist nos dois casos: capturar decisões fáceis de esquecer enquanto a memória ainda está fresca. Quando você usar o Builder OS pra começar o seu segundo produto daqui a 6 meses, vai voltar nesta página e marcar 8/8 do zero, porque o que você decidiu agora é específico do produto atual e não transfere automaticamente.

Takeaways do M2

• Wedge específico é triângulo usuário × tarefa × canal que falha no teste de troca em todos os três elementos.
• Roadmap são 3 fatias verticais, cada uma entregando valor isolado, sem "modelo de dados" virar fatia 1.
• Nome do plano (feat-<slug>) responde pelo menos 2 das 3 perguntas: entrada, saída, edge case brasileiro.
• Acceptance criteria são asserções sim/não com pelo menos 1 número; sem isso, no M3 você não sabe quando a fatia 1 terminou.

Você terminou quando

Você marcou 7 ou mais itens da checklist e tem clareza sobre quais (se algum) precisa fechar antes do Módulo 3.