Lição 7 de 8: O que não cortar
- Os 3 itens não-cortáveis registrados em pelo menos 1 dos 3 documentos (
docs/product.md,docs/roadmap.md, plano da fatia 1) - Commit
docs: clarify non-goals + acquisition channelno GitHub
Na investigação do CEAP, a primeira versão do mapeamento CNAE (código de atividade econômica) classificou prefeituras alugando espaço como "fraude". Era tentador deixar o refino pra depois ("MVP primeiro, ajusto o ruído quando aparecer"). Manter o refino na primeira fatia removeu R$ 1.5 milhões em falsos positivos antes que a análise virasse pública. Cortar essa camada teria queimado a credibilidade da ferramenta no primeiro dia.
Esse é o pattern que esta lição cobre: três coisas que parecem overhead na primeira fatia, mas que, se você cortar, vai precisar voltar pra corrigir antes de duas semanas de uso real.
Não-cortável 1: validação de input na borda
O que é: a rejeita CPF, CNPJ, CEP, email, telefone e valor monetário inválidos antes de qualquer dado entrar no banco. Toda entrada que vem de fora (formulário, API externa, upload) passa por uma função de validação.
Por que precisa ficar na fatia 1: dados inválidos no banco custam mais pra limpar do que pra prevenir. Em uma semana de uso real você vai ter CPFs em formato misto (123.456.789-00, 12345678900), alguns inválidos salvos (123.456.789-XX) e alguns null por checagem esquecida. Reformatar tudo isso depois custa mais do que validar desde o início. O repositório base tem uma regra candidata validate-cpf-on-boundary que aparece na L07 do Módulo 1. Esta lição é o lembrete pra ativá-la agora, não na fatia 2.
Não-cortável 2: observabilidade mínima
O que é: é rastrear de 4 a 6 eventos críticos do funil. Não precisa de dashboard sofisticado nem de Mixpanel/Amplitude/PostHog instalados nesta fatia. Precisa só de uma decisão tomada e de chamadas vazias (console.log por enquanto) nos pontos certos do código.
Por que precisa ficar na fatia 1: quando você lança e o uso é baixo, "ninguém usou" pode significar 5 coisas distintas: usuário não descobriu o produto, descobriu e saiu da home, criou conta e não voltou, usou uma vez e não voltou, usou e funcionou mas não pagou. Sem 4 a 6 eventos rastreados você não distingue entre essas hipóteses, e sem distinguir não sabe o que ajustar. O Módulo 4 instala Plausible/PostHog; o mapa de eventos você decide agora e deixa em chamadas vazias.
Não-cortável 3: canal de aquisição visível
O que é: o canal que você escreveu na seção Wedge do docs/product.md (L02) precisa estar registrado explicitamente em algum lugar do repositório onde Claude lê toda sessão: docs/product.md, docs/roadmap.md ou no plano da fatia 1.
Por que precisa ficar na fatia 1: isso vai além de growth marketing. É deixar visível pra você mesmo qual é a primeira pessoa pra quem você vai mandar mensagem na semana 1 depois do lançamento. Se o canal está só na sua cabeça, no Módulo 4 você vai ter o produto pronto e não vai saber pra quem mandar. "Marketing digital" não é canal específico. Tem que ser específico o bastante pra nomear pessoas reais.
Pergunta de teste: se eu pedir agora "me dá o nome de 3 pessoas reais que cabem no perfil do seu wedge," você consegue responder em 30 segundos? Se sim, o canal está concreto. Se não, está vago.
Passo 1 — Audite o repositório
Pegue os 3 documentos (docs/product.md, docs/roadmap.md e o feat-<nome>.md da fatia 1 dentro de plans/) e rode esta verificação no Claude:
Leia estes 3 arquivos do projeto:
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-`)
Para cada um dos 3 itens não-cortáveis abaixo, responda **PRESENTE** ou **AUSENTE**, e cite qual arquivo é a fonte da resposta. Não invente: se não aparece em lugar nenhum, marque AUSENTE.
**Não-cortável 1 — Validação de input na borda.** Existe pelo menos 1 critério no Acceptance criteria do plano da fatia 1 que rejeita input inválido (CPF, CNPJ, CEP, email, valor)? Existe uma tarefa na Task list que cria a função de validação?
**Não-cortável 2 — Observabilidade mínima.** Existe um mapa de 3 ou mais eventos rastreados em algum dos 3 documentos (pode ser nome de evento + descrição)? Existe uma tarefa na Task list adicionando as chamadas vazias?
**Não-cortável 3 — Canal de aquisição visível.** A seção Wedge do `docs/product.md` tem um canal específico (não "marketing digital," não "redes sociais")? Existe alguma menção a 3 ou mais pessoas/contatos reais em algum dos documentos?
Saída: 3 linhas, cada uma do formato "Não-cortável N: PRESENTE em <arquivo>" ou "Não-cortável N: AUSENTE."Se Claude responder PRESENTE para os 3, vá para o Passo 3. Se algum sair AUSENTE, vá para o Passo 2.
Passo 2 — Adicione o que estiver faltando
Para cada item AUSENTE, adicione no documento apropriado. Patches mais comuns:
Passo 3 — Faça o commit
Faça commit dos ajustes nos 3 documentos (`docs/product.md`, `docs/roadmap.md`, e/ou o plano da fatia 1). Stage os arquivos modificados, com mensagem `docs: clarify non-goals + acquisition channel`.Aprove git add e git commit. Confira no GitHub.
Verificação: leia os 3 documentos em sequência
Abra docs/product.md, depois docs/roadmap.md, depois o feat-<nome>.md, nessa ordem. Em até 90 segundos, você consegue responder em voz alta:
- Quem é o usuário (1 frase)?
- Qual é o canal de aquisição específico (1 frase)?
- Qual input vai ser validado, e qual evento marca o uso central do produto?
Se sim, os 3 itens estão visíveis o suficiente. Se você travou em alguma resposta, aquele item ainda está implícito. Explicite.
Build Diary — os outros 2 não-cortáveis no CEAP
A validação na borda (exemplo do CNAE refinado, R$ 1.5M de falsos positivos removidos) abriu a lição. Os outros dois aparecem como artefatos verificáveis no mesmo projeto: trechos reais de NOTAS_DO_AUTOR.md e feat-tcu-guide-tab.md.
Não-cortável 2 — Observabilidade segmentada
O CEAP tem um sistema de scoring de risco que combina HHI, Benford e outros indicadores. Trecho real do NOTAS_DO_AUTOR.md sobre uma falha do sistema:
O Paradoxo do Sóstenes. O algoritmo classificou Sóstenes como risco MÉDIO. Score 0.319 de 1.0. A PF encontrou R$ 430.000 em dinheiro vivo.
Por que o score falhou? Sóstenes diversificava fornecedores no agregado (HHI geral baixo). A concentração extrema estava em uma categoria específica: locação de veículos.
A lição: Análises agregadas mascaram anomalias específicas. Sempre segmente por categoria antes de concluir.
Observabilidade no agregado (score geral) escondeu o sinal. Observabilidade segmentada (HHI por categoria de despesa) teria exposto. Pra produto, a lição é a mesma: eventos rastreados precisam ser específicos o suficiente pra responder a pergunta certa. "Usuário usou o produto" é agregado demais. "Usuário emitiu recibo no fluxo X às terças" é específico.
Não-cortável 3 — Canal de aquisição visível
O feat-tcu-guide-tab.md (visto na L05) abre declarando explicitamente o canal: "The TCU's coLAB-i team is meeting with us to see the dashboard." O canal não está implícito. Está na primeira frase do plano da feature.
Isso forçou decisões consistentes: tom da página ("we're sharing something useful, not selling"), escolha de casos a destacar (a Operação Galho Fraco, caso real da PF, em vez de exemplos genéricos) e CTA final ("low-pressure how we can work together"). Sem o canal explícito, qualquer dessas decisões viraria chute.
Takeaways
- Validação na borda fica na fatia 1, não na 2: limpar dado inválido depois custa mais do que rejeitar agora.
- Observabilidade mínima = 4-6 eventos do funil mapeados, com chamadas vazias no código. PostHog/Plausible vem no Módulo 4; a decisão de quais eventos importa agora.
- Canal de aquisição precisa ser específico o bastante pra nomear 3 pessoas reais (ou 3 personas-arquétipo com canal nomeado, se você ainda não tem rede prévia).
- Cada não-cortável vira uma linha concreta no repositório (Acceptance criteria, evento mapeado, frase no Wedge), e não princípio genérico.
Você terminou quando
Os 3 itens não-cortáveis (validação na borda, observabilidade mínima, canal específico) estão registrados em pelo menos 1 dos 3 documentos cada, e os ajustes estão commitados no GitHub.