Como eu fiz
um app do zero

O que você vai fazer neste passo

Criar um arquivo de regras que a inteligência artificial vai ler sozinha, toda vez que você abrir o projeto. Esse arquivo se chama CLAUDE.md e fica na pasta principal do app.

Você não precisa mandar essas regras de novo a cada conversa. Ela lê antes de responder qualquer coisa.

Por que isso importa

Sem esse arquivo, a IA esquece tudo entre uma conversa e outra. Você explica como quer o app hoje, e amanhã ela faz do jeito dela de novo.

Pior: ela tende a fazer mais do que você pediu. Instala biblioteca que você não autorizou, “melhora” código que estava funcionando, inventa dado falso pra tela não ficar vazia. O arquivo de regras é o que segura isso.

Pense nele como o contrato de trabalho de um funcionário novo. Você não repete as regras da empresa toda manhã, elas estão escritas.

Quando fazer

Primeiro de tudo. Antes de desenhar tela, antes de escrever uma linha de código, antes de criar conta em qualquer serviço.

1. O prompt (cole isso)

Abra a pasta do seu projeto na IA e cole o texto abaixo, do começo ao fim, incluindo a primeira linha.

Os trechos entre colchetes [assim] são os que você troca. O resto vai igual.

Crie um CLAUDE.md na raiz do projeto com o conteúdo abaixo, exatamente
como está.

# [NOME DO SEU APP]

## Comportamento

**Cautela > velocidade.** Para tarefa trivial, use bom senso.

- **Pense antes de codar.** Diga suas suposições. Se há mais de uma
  interpretação, mostre as opções, não escolha em silêncio. Se estiver
  confuso, pare e pergunte.
- **Simplicidade.** Código mínimo que resolve o problema. Sem feature não
  pedida, sem abstração pra uso único, sem "flexibilidade" especulativa.
- **Cirúrgico.** Toque só no que precisa. Não "melhore" código adjacente
  nem formatação. Combine com o estilo existente.
- **Critério de sucesso.** Tarefa vaga → meta verificável. Em tarefa de
  vários passos, declare o plano e como verificar cada etapa antes de
  começar.
- **Reporte decisões fora do pedido.** Ao fim da tarefa, liste o que você
  decidiu, mudou ou trocou que eu não pedi, e os tradeoffs. Sugira o que
  vale virar regra permanente, mas não edite este arquivo sozinho.
- **Quando eu apanhar de um problema, proponha a regra.** Todo erro que
  custou mais de uma tentativa pra achar termina com uma proposta de regra
  nova, escrita como "o que impede isso de voltar". Eu aprovo antes de
  entrar.

## Stack

- [tecnologia do app], versão [XX]
- [onde ficam os dados e o login]
- [como cobrar assinatura, se for cobrar]

## Decisões de arquitetura

Cada decisão leva um (Por quê: ...) e uma marca:
  [LEI] = regra técnica ou de segurança. Não se discute.
  [APOSTA] = escolha de produto que parece boa hoje. Se a construção
             começar a ficar cara, revisar antes de insistir.

- [LEI] O aplicativo não tem servidor próprio. O que for sensível roda em
  [camada de backend].
  (Por quê: a plataforma já cobre banco, login e funções; servidor próprio
  é custo à toa.)
- [LEI] O que é grátis e o que é pago é decidido no servidor, nunca dentro
  do aplicativo.
  (Por quê: o que está dentro do app pode ser burlado por quem sabe mexer.)
- [LEI] Chamadas a inteligência artificial e a serviços externos passam
  pelo servidor. A senha de acesso desses serviços nunca vai dentro do app.
  (Por quê: senha embutida no aplicativo é extraída em minutos por qualquer
  pessoa.)
- [APOSTA] Ordem de entrada do usuário: [descreva].
  (Por quê: [seu motivo].)

## Comandos

- Rodar o app: [comando]
- Checar erros: [comando]
- Depois de cada commit, rodar o push também.

## Estrutura

[as pastas do projeto e o que mora em cada uma]

## Convenções

- Cor, tamanho e espaçamento sempre pelos tokens do design system.
  Nunca escrever a cor direto na tela.
- Ícones de biblioteca. NUNCA emojis na interface.
- Tipos simples e legíveis.

## Regras do projeto (IMPORTANTE)

- Sem dado inventado. Ou é dado de verdade, ou é tela vazia com mensagem.
- Quando eu mandar uma imagem de referência, copie fielmente: layout,
  espaçamento, fonte, cor, cantos e sombra. Não aproxime sem pedir.
- Uma fase por vez. Mostrar o plano e esperar minha aprovação antes de
  executar.
- Não instale bibliotecas novas sem minha aprovação.
- Antes de terminar qualquer tarefa, rode o checador de erros e corrija o
  que aparecer.
- Toda vez que eu precisar rodar algo no banco de dados, cole o código
  inteiro na resposta, aberto, pronto pra copiar e colar, nunca só o
  caminho do arquivo. Junto, o passo a passo de onde clicar.
- Correção feita direto no painel do banco vira arquivo de migration na
  mesma resposta, nunca depois.
- No começo de cada tarefa, diga em uma linha qual modelo de IA se encaixa
  melhor nela.

## Variáveis de ambiente (.env)

[lista dos nomes, sem os valores]

Como preencher os colchetes

Não trave o que você ainda não testou. Se não tem certeza de uma escolha de produto, escreva [APOSTA] e siga. Marcar errado como [LEI] faz você construir semanas em cima de uma decisão que ninguém revisa.

2. O que esperar da IA

Ela vai criar o arquivo e confirmar. Leva menos de um minuto e ela não deve fazer pergunta nenhuma: é só transcrição.

Confira antes de seguir: abra o arquivo e leia. Se ela reescreveu com as palavras dela, resumiu ou “melhorou” alguma seção, mande refazer copiando exatamente o que você colou.

3. O que aconteceu comigo

Essa foi a primeira mensagem do Vem Treinar, em 27 de julho de 2026, às 19h28. Escrevi seis palavras e colei o modelo. O arquivo ficou pronto em trinta segundos.

Cinco semanas depois, esse arquivo tinha 818 linhas e havia sido alterado em 31 commits. Ele começou com umas 90 linhas.

Ele cresceu porque virou o lugar onde eu anotava as armadilhas, não o conserto do problema, mas a regra que impede o problema de voltar. Três exemplos que estão lá até hoje:

• “Toda coluna nova precisa de uma permissão própria.” Escrito depois de eu esquecer isso duas vezes e o formulário salvar tudo, menos aquele campo.
• “Toda função nova do banco precisa ser fechada.” Escrito depois de eu descobrir que o banco de dados libera funções novas para qualquer pessoa da internet, sem conta, por padrão.
• “Antes de reescrever algo que já existe, ache a versão mais recente.” Escrito depois de eu apagar sem querer, de uma vez, três correções antigas.

Nada disso estava no modelo do curso, nem poderia estar. O modelo não te dá as regras certas. Ele te dá o lugar onde as regras certas vão morar quando você aprendê-las.

O erro que eu cometi, e você pode evitar

O modelo do curso trazia duas decisões escritas com toda a confiança do mundo:

Fluxo: Onboarding → Paywall → Cadastro, nessa ordem. As respostas ficam guardadas no aparelho e vão pro banco depois do cadastro.

Ou seja: a pessoa responde as perguntas iniciais antes de criar conta, e o app guarda tudo no celular pra transferir depois.

Eu inverti as duas. No Vem Treinar a conta é criada primeiro, e só depois vêm as perguntas. E não existe tela de assinatura no caminho de entrada.

O que eu ganhei com isso: com a conta já criada, as perguntas do início gravam direto no banco. Sumiu uma camada inteira de trabalho, não teve código de transferência pra escrever, nem dado duplicado em dois lugares, nem o problema de “a pessoa respondeu tudo e o cadastro falhou no fim”.

A lição não é que o curso errou. Aquelas duas decisões fazem sentido em app que vende assinatura logo de cara. A lição é que elas vinham no modelo com a mesma cara de definitivo que “senha nunca vai dentro do app”, e não são a mesma coisa. Uma é regra de segurança. A outra é palpite de venda.

Por isso o prompt deste capítulo tem [LEI] e [APOSTA]. É a única mudança grande que fiz no modelo, e é a que mais te protege.

4. Armadilhas

Escrever regra sem o porquê. Daqui a três semanas você não vai lembrar por que decidiu aquilo, e vai mudar sem perceber o que quebra. Todo item leva (Por quê: ...).

Deixar a IA editar o arquivo sozinha. Ela vai querer. Se deixar, um dia você abre e não reconhece as próprias regras. O prompt já proíbe isso.

Achar que está pronto. Não está. Esse arquivo é o único do projeto que cresce até o fim. Se depois de um mês ele estiver do mesmo tamanho, sinal de que você não anotou o que aprendeu.

5. Terminou quando

• O arquivo existe na pasta principal do projeto.
• Você leu ele inteiro e entende cada linha.
• Toda decisão tem (Por quê: ...) e a marca [LEI] ou [APOSTA].
• Existe pelo menos uma [APOSTA]. Se está tudo como [LEI], você não pensou o suficiente.
• Numa conversa nova, a IA cita alguma regra do arquivo sem você mandar.

Resumo do capítulo

O que você vai fazer neste passo

Gerar uma única imagem com todas as telas principais do seu app, desenhadas lado a lado, como se o app já existisse e estivesse publicado na loja.

Essa imagem não é decoração. Ela vira a fonte da verdade do visual: no passo seguinte, a IA lê essa imagem e extrai dela as cores, as fontes, os tamanhos e o formato dos botões pra escrever o código.

Por que isso importa

Descrever um app em palavras não funciona. “Quero um visual moderno e limpo” significa uma coisa pra você e outra pra IA, e você só descobre a diferença quando as telas ficam prontas e feias.

Com a imagem pronta antes, você decide o visual olhando, não imaginando. E corrigir uma imagem custa minutos; corrigir vinte telas já codadas custa dias.

Quando fazer

Depois do arquivo de regras (capítulo 1) e antes de qualquer código.

⚠️ Uma ressalva importante que eu aprendi errando, leia a seção “O que aconteceu comigo” antes de rodar este passo. Existe um capítulo mais pra frente (a personalidade da marca) que provavelmente deveria vir antes deste.

1. Onde rodar este prompt

Não é no mesmo lugar dos outros. Os prompts deste livro são colados numa IA que escreve código. Este aqui gera imagem, então precisa de um gerador de imagens.

Serve qualquer um que aceite um pedido longo em texto e devolva imagem em alta resolução. Eu usei dois diferentes e ficou bom nos dois.

Você vai salvar a imagem no computador e usá-la no capítulo seguinte.

2. O prompt (cole isso)

Você é um designer de produto world class, especialista em apps mobile que
atingem milhões de downloads.

Sua referência de qualidade são apps como Duolingo, Headspace e Strava, além
dos padrões de design da Apple.

Sua tarefa é transformar a ideia abaixo em um DESIGN SYSTEM COMPLETO + TODAS
AS TELAS DO APP EM FORMATO DE MOCKUP VISUAL.

IDEIA DO APP:
[DESCREVA SEU APP AQUI EM 2 OU 3 FRASES]

## FORMATO DE SAÍDA (OBRIGATÓRIO)

- NÃO explique
- NÃO descreva
- NÃO escreva textos longos

Gere DIRETAMENTE:
UMA IMAGEM GRANDE (alta resolução)
CONTENDO TODAS AS TELAS DO APP
ORGANIZADAS LADO A LADO

## TELAS OBRIGATÓRIAS

1. Tela de entrada (login / criar conta)
2. Tela principal (a primeira que a pessoa vê depois de entrar)
3. Tela da ação principal do app
4. Tela secundária (histórico, progresso, agenda)
5. Perfil / configurações

## REGRAS DE DESIGN (CRÍTICAS)

Sistema visual:
- minimalista, limpo e moderno
- aparência de app real publicado

Espaçamento e layout:
- grid de 8 pontos (8, 16, 24, 32...)
- margens laterais de 16
- espaçamento consistente entre elementos

Hierarquia:
- 1 ação principal por tela
- leitura em menos de 2 segundos
- poucos estilos de texto

Anti-interface amadora:
- NÃO usar frases motivacionais
- NÃO adicionar textos inúteis
- NÃO criar cards sem função
- NÃO repetir informação
Se um elemento não tem função clara, NÃO inclua.

Componentes:
- botões consistentes entre telas
- cores com função definida (uma cor de destaque, não cinco)

Espaço vazio:
- usar de forma intencional, interface com respiro

## VALIDAÇÃO ANTES DE GERAR

- remover qualquer elemento inútil
- simplificar ao máximo
- garantir consistência entre todas as telas

## REGRA FINAL

Se a interface parecer "cheia", está errada.
Se parecer simples e óbvia, está correta.

Gere apenas a imagem. Numere e nomeie cada tela embaixo dela.

Como preencher

Exemplo de “IDEIA DO APP” bem escrita, no formato certo:

App para encontrar parceiros de treino na academia. A pessoa vê quem treina perto dela e no mesmo horário, envia um convite, e quando o outro aceita os dois marcam o treino. Público: quem treina sozinho e quer companhia.

3. O que esperar

Uma imagem com as 5 telas em fila, cada uma numerada e nomeada embaixo.

Não aceite a primeira. Gere de novo, mudando o que não gostou. É barato e rápido. Eu gerei duas versões e a segunda ficou bem melhor que a primeira: ganhou os botões de login social, um filtro a mais na busca e foto de verdade no lugar de bolinha com iniciais.

Guarde o arquivo numa pasta que você vai lembrar. Você vai precisar dele no próximo capítulo, e não é raro precisar de novo meses depois.

4. O que aconteceu comigo

O mockup mandou no app inteiro

A imagem que eu gerei em 27 de julho definiu coisas que continuam de pé até hoje: o fundo escuro, o laranja como única cor de destaque, a barra de abas embaixo, e o botão “Combinar treino”, que virou o nome oficial da ação principal do app, não só um texto de botão.

Foi o passo mais barato com o efeito mais duradouro do projeto inteiro.

O erro que me custou retrabalho

O mockup mostrava a sequência de dias treinados com um ícone de chama, do lado de “12 dias seguidos”. Bonito, e igualzinho ao que todo app de fitness faz.

Um mês depois, exatamente, eu fiz o capítulo da personalidade da marca (o prompt 11 deste livro). O resultado desse trabalho dizia, com todas as letras, que chama, confete e troféu são clichê da categoria e que meu app não devia usar nenhum dos três.

Tive que voltar e trocar. A chama virou um símbolo de dois “certos” se encaixando, que combina com a ideia do app (duas pessoas cumprindo o combinado) e não parece qualquer outro app de academia.

Se eu tivesse definido a personalidade da marca antes de desenhar, teria desenhado certo de primeira. É a maior correção que eu faço à ordem do curso neste livro.

O mockup desobedeceu o próprio prompt

Um detalhe que vale você conferir no seu: o prompt diz, em maiúsculas, “NÃO usar frases motivacionais”. A imagem que ele gerou colocou, no perfil, três etiquetas escritas “Foco · Motivação · Disciplina”.

A IA que gera imagem não obedece tão bem quanto a que escreve código. Leia a imagem procurando o que você proibiu, vai achar.

O que ficou no desenho e nunca foi construído

O mockup tinha uma conversa em grupo chamada “Team VEM TREINAR”. Nunca construí. Cinco semanas depois, o app não tem chat em grupo e ninguém sentiu falta.

Isso não é problema: é o mockup fazendo o trabalho dele. É muito mais barato descobrir que você não quer uma tela olhando pra ela do que construindo ela.

5. Armadilhas

Gerar uma imagem por tela, em vez de todas juntas. O prompt pede uma imagem só, com as telas lado a lado, de propósito: é assim que você enxerga se elas combinam entre si. Telas geradas separadas quase sempre saem com cores e tamanhos ligeiramente diferentes.

Aceitar pessoas e nomes falsos como se fossem conteúdo. O mockup vem cheio de “Mariana, 26” e “Smart Fit Asa Sul”. Isso é enfeite pra imagem ficar convincente, não é conteúdo do seu app. No próximo capítulo a IA vai trocar tudo isso por espaços vazios, e está certa.

Deixar o desenho decidir a marca. Foi o meu erro. O desenho decide como o app se parece; a marca decide o que ele é. Quando a ordem se inverte, você desenha clichê sem perceber.

6. Terminou quando

• Você tem uma imagem, com todas as telas lado a lado, salva numa pasta.
• Cada tela está numerada e nomeada.
• Existe uma cor de destaque só, usada sempre pra mesma coisa.
• Você olhou a imagem procurando o que o prompt proibiu (frase motivacional, card sem função, informação repetida) e não achou.
• Você consegue apontar, na imagem, qual é a ação principal do app.

Resumo do capítulo

O que você vai fazer neste passo

Transformar a imagem do capítulo anterior em código de verdade: as telas navegáveis, com as cores e fontes certas, os botões no lugar, só que ainda vazias, sem dado nenhum.

No fim deste passo você abre o app no celular e navega entre as telas. Elas não fazem nada ainda, mas já são o seu app.

Por que isso importa

Este é o passo que decide se o resto do projeto vai ser fácil ou sofrido.

A IA vai criar um design system: um arquivo central onde ficam guardadas todas as cores, tamanhos de texto e espaçamentos, cada um com um nome. Daí em diante, nenhuma tela escreve uma cor direto, todas pedem pelo nome.

Parece detalhe. Não é. Foi o que me permitiu, cinco semanas depois, adicionar um tema claro no app inteiro sem reescrever tela nenhuma.

Quando fazer

Depois da imagem pronta. É o primeiro passo que gera código.

1. O prompt (cole isso)

Anexe a imagem do capítulo anterior junto com este texto.

A pasta já tem um CLAUDE.md com as regras, decisões e stack do projeto. Use
ele como contrato.

Crie aqui um projeto [TECNOLOGIA] usando a versão indicada no CLAUDE.md, e em
seguida faça o esqueleto das telas e o design system.

// REFERÊNCIA VISUAL
A imagem anexada é a fonte da verdade do visual. Extraia para tokens:
- Paleta: cor principal, fundo, cards, texto principal e secundário, e as
  cores de destaque ou de estado que aparecerem
- Tipografia: hierarquia, pesos e tamanhos
- Raio de borda de cards e botões, sombras e espaçamentos
- Anatomia dos componentes: botão principal e secundário, cards, linhas de
  lista, e qualquer componente específico que você identificar na imagem

Se houver mascote ou ilustração, deixe um espaço reservado e me liste os
arquivos que preciso te fornecer depois. Não tente recriar o personagem.

// TELAS
Extraia da imagem, na ordem em que aparecem. Se alguma coisa estiver ambígua
ou faltando, me pergunte antes de assumir.

// O QUE FAZER
Design system global num lugar central, componentes reutilizáveis, navegação
entre as telas, e as telas esqueleto. Replique o layout fielmente, com
espaços reservados e estados vazios.

Instale o que faltar, listando antes o que vai instalar e por quê. Inclua a
fonte mais próxima da referência.

Crie o arquivo .env com as variáveis listadas no CLAUDE.md, sem valores ainda.

Não crie banco de dados nem login nesta fase.

No plano que você vai me mostrar antes de executar, inclua: a paleta e os
tokens extraídos da imagem, a lista de componentes, e a estrutura de
navegação.

Como preencher

Sobre deixar as telas em branco: o modelo do curso pede pra você listar cada tela e cada elemento à mão. Eu não listei, deixei a instrução genérica e apostei que a imagem bastava. Bastou. A IA leu a imagem e listou as telas sozinha, e ainda achou uma inconsistência que eu não tinha visto.

Se o seu app for mais complexo que uma lista de telas óbvias, aí sim vale descrever.

2. O que esperar da IA

Ela vai te mostrar um plano antes de escrever qualquer coisa: é o que o arquivo de regras do capítulo 1 obriga. O plano vem com:

• a paleta que ela leu da sua imagem, cor por cor, com o código de cada uma
• a fonte escolhida e os tamanhos de cada tipo de texto
• a lista de componentes que ela vai criar
• o mapa de navegação entre as telas
• o que ela vai instalar, e por quê

Leia o plano com atenção: é o momento mais importante deste capítulo. Uma cor errada aqui vira uma cor errada em quarenta telas depois.

Confira principalmente:

• A cor de destaque está certa? (compare com a imagem)
• O fundo está certo? (escuro ou claro, como você quis)
• A ordem das abas está igual à da imagem?

Aprove só depois de conferir. Se algo estiver errado, corrija no plano, não depois.

3. O que aconteceu comigo

A IA achou o que eu não mostrei

Eu colei seis imagens de tela. Antes de fazer o plano, a IA foi olhar a pasta do projeto por conta própria e encontrou uma outra pasta com mais imagens. Verificou uma a uma, e me avisou:

“Boa notícia: as imagens da outra pasta são as mesmas 6 telas que você colou aqui. O escopo visual está fechado em 6 telas, sem tela oculta.”

Achou também dois arquivos soltos que não tinham nada a ver com o projeto e avisou que ia deixá-los intocados. Isso é o “cirúrgico” do arquivo de regras funcionando.

Ela achou um erro no meu mockup

Dentro do plano, escondida entre as suposições:

“Os mockups variam levemente o ícone do ‘Feed’ entre telas (casa vs. bússola). Vou padronizar em um único conjunto consistente nas 5 abas.”

Eu não tinha percebido. O gerador de imagem tinha desenhado uma casinha numa tela e uma bússola na outra, pra mesma aba. Se ela não tivesse avisado, o app ia nascer com esse defeito.

O dado falso morreu aqui

O mockup era cheio de gente inventada: “Mariana, 26”, “Rafael, 28”, “Smart Fit Asa Sul”. A IA olhou pra regra “sem dado inventado” do capítulo 1 e decidiu:

“Como a regra do projeto é ‘sem mock data’, vou usar espaços reservados neutros em vez de inventar pessoas.”

Foi a decisão certa. App cheio de gente falsa parece pronto quando não está, e você passa semanas sem perceber que a tela nunca foi ligada em nada.

O que sobreviveu cinco semanas

Aqui está o retorno real deste capítulo. As cores que a IA extraiu da imagem naquela noite ganharam nomes: background, surface, border, primary, textPrimary, textSecondary e mais alguns.

Cinco semanas e 144 alterações depois, dez desses onze nomes continuam exatamente iguais no código. O que mudou foi só o valor de cada um, e mudar o valor num arquivo central troca a cor no app inteiro de uma vez.

Foi assim que o app ganhou tema claro sem que eu precisasse abrir tela por tela.

Teve até um detalhe curioso: a IA criou uma cor que ela mesma disse não ter encontrado uso (“não identifiquei uso, reservo”). Semanas depois, essa cor achou função, virou o fundo translúcido dos ícones.

Um detalhe sobre modelo de IA

Depois de ler o plano e antes de mandar executar, eu troquei para o modelo mais forte disponível. Este passo escreve dezenas de arquivos de uma vez e é o alicerce de todo o resto, não é hora de economizar.

4. Armadilhas

Aprovar o plano sem ler. É o erro mais caro deste capítulo. O plano tem os códigos das cores escritos; conferir leva dois minutos e evita retrabalho em todas as telas.

Deixar a IA escolher “a versão mais recente” da tecnologia. Peça a versão que está no seu arquivo de regras, mesmo que exista uma mais nova. Versão mais nova costuma ter bibliotecas ainda não compatíveis, e você descobre isso três capítulos depois.

Aceitar tela bonita que não navega. No fim deste passo você tem que conseguir tocar nas abas e trocar de tela. Se não navega, não terminou.

Escrever cor direto na tela “só dessa vez”. Não existe “só dessa vez”. Uma cor solta hoje são quarenta amanhã, e aí o tema claro fica impossível.

5. Terminou quando

• O app abre no seu celular ou no simulador.
• Você navega entre todas as abas tocando nelas.
• As cores batem com a imagem do capítulo anterior.
• Existe um lugar central com as cores nomeadas, e nenhuma tela tem cor escrita direto.
• As listas aparecem vazias, não cheias de gente inventada.
• O checador de erros roda limpo.

Resumo do capítulo

O que você vai fazer neste passo

Decidir quais dados o seu app vai guardar e criar o lugar onde eles ficam.

Até agora suas telas estão vazias porque não existe nada guardado em lugar nenhum. Este passo cria as “gavetas”: uma pra perfil de usuário, uma pra cada coisa que o app registra.

Você também vai criar a conta no serviço que hospeda esses dados.

Por que isso importa

É o passo mais difícil de desfazer.

Trocar a cor de um botão depois é fácil. Descobrir no mês seguinte que você guardou a data de um jeito errado, com trezentos registros já salvos, é uma dor de cabeça de verdade.

Por isso este prompt é o mais rigoroso do livro: ele proíbe a IA de inventar. Cada dado que entrar no banco precisa ter prova de que alguma tela do seu app realmente pede por ele.

Quando fazer

Depois do esqueleto pronto. A IA precisa ler as telas pra saber que dados elas pedem, por isso não dá pra fazer antes.

1. O prompt (cole isso)

Analisa o código deste projeto e o CLAUDE.md, e propõe o schema do banco de
dados pra atender o que o código exige hoje E o que está mapeado pra fases
futuras no CLAUDE.md. O schema deriva só de evidência, não invente campos
só porque são comuns nesse tipo de app.

ANTES DE QUALQUER COISA, verifica se o ambiente está pronto:
- O arquivo .env tem o endereço e a chave do banco preenchidos com valores
  reais (não placeholder)?

Se não estiver, me guia passo a passo, em português comum e sem termo
técnico, por:
- Criar conta e projeto no serviço, escolhendo a região mais próxima do meu
  público.
- Onde encontrar o endereço e a chave no painel.
- Como colar esses valores no .env.

Só segue pro próximo passo depois de eu confirmar que está tudo pronto.

Escopo: só o banco de dados. Não implementa login, funções de servidor,
onboarding nem cobrança, essas vêm em fases seguintes.

Antes de criar qualquer arquivo, me entrega:

1. RESUMO EM LINGUAGEM DE PRODUTO. Em português comum, sem termo técnico,
   me explica que dados o app vai guardar. Essa é a parte que eu reviso pra
   confirmar se reflete o que meu app precisa.

2. CLASSIFICAÇÃO. Pra cada dado, diga qual destes é:
   CONFIRMADO, alguma tela do código pede esse dado hoje
   PLANEJADO, está escrito no CLAUDE.md como fase futura
   HIPÓTESE, provável, mas sem prova no código
   DECISÃO, depende de uma escolha minha
   Mostre a evidência de cada um (qual arquivo, qual tela).
   Só CONFIRMADO e PLANEJADO entram no schema final.

3. PONTOS DE DECISÃO. Em português comum, liste o que precisa que eu
   responda antes de você executar.

4. SCHEMA TÉCNICO (essa parte é pra você executar, eu não preciso entender).
   Tabelas, colunas, permissões, índices, gatilhos, armazenamento de
   arquivos. Cobre obrigatoriamente:
   - Segurança por linha ativada em TUDO que pertence a um usuário, de forma
     que cada pessoa só alcance os próprios dados.
   - Espaço de arquivos privado, se o app guarda fotos, com permissão por
     usuário.

Quando eu aprovar:
- Escreve cada alteração do banco como um arquivo separado e numerado, numa
  pasta de migrations. Esses arquivos são a fonte da verdade do banco.
- Me guia, em português comum, a aplicar cada um: copia o conteúdo do
  arquivo, abre o editor de SQL no painel, cola, e clica em executar. Na
  ordem dos arquivos.

Espera minha aprovação antes de criar os arquivos.

Como preencher

Nada. Este prompt vai inteiro, sem trocar nada: ele lê o seu projeto e deduz o resto.

2. O que esperar da IA

Primeiro ela vai te parar

A primeira coisa que ela faz é conferir se você já tem conta no serviço de banco de dados. Se não tiver, ela para tudo e te guia pra criar.

Isso é de propósito. Não pule.

Quando a IA te mandar escolher a região do banco, escolha a mais perto do seu público, não de você. Isso muda a velocidade do app pra quem usa.

Depois ela te entrega quatro coisas

1. Um resumo em português. Uma lista do que o app vai guardar, sem termo técnico. É a única parte que você precisa entender de verdade. Leia com atenção e pergunte: falta alguma coisa? Tem coisa demais?

2. Uma tabela de classificação. Aqui está o coração deste capítulo. Cada dado vem marcado com a prova de por que ele existe.

3. Pontos de decisão. Perguntas que só você pode responder.

4. O plano técnico. Você não precisa entender. Pode passar por cima.

3. O que aconteceu comigo

O prompt me mandou sair da cadeira

Rodei o prompt às 23h35. A IA conferiu o arquivo de configuração, viu que estava vazio, e parou, me mandou criar a conta no serviço.

Voltei 38 minutos depois e escrevi uma palavra: “PRONTO”.

Esse é o prompt funcionando. Sem esse portão no começo, a IA teria escrito todo o banco de dados e só na hora de aplicar é que eu descobriria que não tinha onde aplicar.

A tabela que impediu a IA de inventar

Foi a parte mais útil da resposta inteira. Três linhas reais dela:

Repare no que aconteceu. O mockup mostrava “4.9 de avaliação” e “1.2k seguidores”, números bonitos, colocados ali pela IA de imagem só pra tela ficar convincente.

Uma IA sem essa regra teria criado tabelas de avaliação e de seguidores inteiras, com toda a estrutura, adivinhando como funcionariam. Trabalho pra um problema que ainda não existia, e provavelmente adivinhado errado.

Em vez disso, ela guardou o campo (porque a tela mostra) e avisou que o mecanismo era palpite meu, não dela.

No fim da resposta, uma frase que vale o capítulo:

“Só entrou no schema o que está nessa tabela, nada de ‘toda rede social tem X’ sem essa evidência.”

As duas perguntas que mudaram o app

Pergunta 1: as etiquetas do perfil (“Musculação”, “Hipertrofia”, “Intermediário”) viram categorias fixas, com opções pré-definidas, ou texto livre?

Ela explicou o motivo de perguntar: “categorias fixas filtram melhor depois”.

Escolhi fixas. Cinco semanas depois, o app tem filtro de busca funcionando, que só é possível porque as opções são fixas. Se eu tivesse escolhido texto livre, quem escrevesse “musculacao” sem cedilha nunca apareceria pra quem filtrasse por “Musculação”.

Pergunta 2: como calcular a distância entre duas pessoas?

Guardar as coordenadas do celular, ou só cidade e bairro em texto? Escolhi coordenadas. Foi o que permitiu, semanas depois, a busca por raio de quilômetros, e também o bloqueio de cadastro fora da minha cidade de lançamento.

As duas decisões levaram trinta segundos cada e valeram semanas de trabalho evitado. Se a IA não tivesse perguntado, ela teria escolhido sozinha, e eu descobriria a escolha errada muito depois.

4. Armadilhas

Aprovar o resumo em português sem ler. É a única parte que você entende, e é a parte que decide o resto. Se o resumo diz que o app guarda algo que você não quer, fale agora.

Deixar HIPÓTESE virar tabela. Se a IA marcou algo como hipótese, ela está dizendo “isso é palpite meu”. Não deixe entrar no banco.

Aplicar as alterações fora de ordem. Os arquivos são numerados por um motivo: o segundo costuma depender do primeiro. Aplique na ordem, um de cada vez, e confira se cada um deu certo antes do próximo.

Achar que o banco fica pronto agora. Ele não fica. Cada capítulo seguinte vai acrescentar coisa. O que este passo cria é a base, e, principalmente, o hábito de que toda mudança no banco vira um arquivo numerado, nunca uma mexida solta no painel que ninguém registra.

5. Terminou quando

• Você tem conta no serviço e um projeto criado, na região certa.
• O arquivo de configuração tem os valores reais preenchidos.
• Você leu o resumo em português e ele descreve o seu app.
• Nenhum dado marcado como HIPÓTESE virou tabela.
• Existe uma pasta com os arquivos numerados de alteração do banco.
• Você aplicou todos, na ordem, e cada um respondeu com sucesso.
• No painel, as tabelas aparecem com a proteção por usuário ligada.

Resumo do capítulo

O que você vai fazer neste passo

Fazer o cadastro e o login funcionarem de verdade: a pessoa cria conta com email e senha, confirma com um código de 6 dígitos, entra no app, e continua entrada quando fechar e abrir de novo.

Inclui também o “esqueci minha senha”.

Por que isso importa

É o que separa um protótipo de um app. Sem conta, cada pessoa que abre o app vê a mesma coisa, e nada do que ela faz fica salvo.

E tem um detalhe de segurança que o prompt resolve por você: uma vez que existe login, cada pessoa só enxerga os próprios dados. Isso não vem de graça: é a proteção que você ligou no capítulo anterior, que só passa a valer agora que existe um “quem” pra proteger.

Quando fazer

Depois do banco de dados criado e aplicado. O login precisa de um lugar pra guardar a conta.

1. Uma escolha antes de começar: código ou link?

Quando alguém cria conta, o app precisa confirmar que o email é real. Existem dois jeitos:

Link no email. A pessoa recebe um email com um botão, clica, e o navegador abre e devolve pro app. É o padrão da maioria dos serviços.

Código de 6 dígitos. A pessoa recebe um número, volta pro app e digita.

Este livro usa código, e recomendo que você use também.

O motivo é prático: o link precisa de uma configuração chamada deep link, que faz o navegador saber voltar pro seu app. Ela quebra com facilidade, funciona diferente em cada celular, e é uma das coisas mais chatas de testar. O código de 6 dígitos funciona igual em qualquer aparelho, sem configuração nenhuma.

O prompt abaixo já está escrito pra código.

2. O prompt (cole isso)

Integre o sistema de login no app. Use o CLAUDE.md como contrato.

ANTES DE QUALQUER COISA, verifica:
- O .env tem o endereço e a chave do banco preenchidos com valores reais?
- O schema do banco está aplicado, e o gatilho que cria o perfil quando
  alguém se cadastra está funcionando?
Se algo faltar, me guia passo a passo em português comum, sem termo técnico.

Escopo: email e senha é o método principal. Se houver botões de Google ou
Apple na tela, ficam visíveis mas inativos por enquanto. Sem onboarding,
cobrança ou funções de servidor aqui.

Confirmação de email por CÓDIGO DE 6 DÍGITOS enviado por email, não por link.
Inclui a tela de digitar o código no fluxo de cadastro. A tela de código tem:
campo do código, botão "reenviar" com espera de 1 minuto, e mensagem clara
para código errado e código vencido.

Recuperação de senha também por código de 6 dígitos, não por link. Reutiliza
a mesma tela de código. Depois de acertar o código, vai pra tela de nova
senha; depois de salvar, entra no app. Nenhum passo desse fluxo abre o
navegador.

Antes de criar arquivos, me entrega:

1. RESUMO EM PRODUTO. Em português comum, o que o app faz em cada caso:
   criar conta, digitar o código, entrar, errar a senha, esquecer a senha,
   sair, e abrir o app já logado.

2. PONTOS DE DECISÃO em português comum.

3. PLANO TÉCNICO. Cobre: sessão que continua salva quando fecha o app,
   estado de login compartilhado entre as telas, cadastro, tela de código
   reutilizável para cadastro e recuperação, login, recuperação de senha,
   direcionamento automático conforme a pessoa está logada ou não, e sair
   da conta.

4. MANUAL DO PAINEL. Liste tudo que eu preciso configurar fora do código,
   no painel do serviço, com o passo a passo de onde clicar. Não presuma
   nada como já feito.

Espera minha aprovação antes de criar arquivos.

Como preencher

Nada. Vai inteiro.

O item 4 (MANUAL DO PAINEL) é o acréscimo mais importante deste capítulo, e a próxima seção explica por quê.

3. O que esperar da IA

Ela vai verificar o ambiente e te entregar o plano. Mas o que importa aqui é outra coisa:

Ela vai te avisar de um bloqueio que só você pode resolver.

Existem coisas neste passo que não têm como ser feitas por código: são ajustes no painel do serviço, e só quem tem a senha da conta consegue fazer. A IA consegue te dizer exatamente onde clicar, mas não consegue clicar.

Leia esse aviso com atenção e resolva antes de mandar ela executar.

4. O que aconteceu comigo

O aviso que salvou o capítulo

No meio da resposta, antes de qualquer plano, veio isto:

⚠️ Um bloqueio que você precisa resolver no painel

Do jeito que o serviço vem configurado, o email de confirmação manda um LINK, não um código de 6 dígitos. Se não mexer nisso, a tela de código nunca vai receber código nenhum.

Isso não dá pra fazer por código: é ajuste no painel, e só você tem acesso.

Ou seja: o serviço vem configurado pra mandar link. Eu podia ter todo o código do mundo pronto pra receber um código de 6 dígitos, e o email ia chegar com um botão de clicar.

O conserto são dois modelos de email a editar no painel, cinco minutos. Mas descobrir isso depois de tudo codado seria uma tarde inteira achando que o bug estava no meu código.

É por isso que o prompt tem o item “MANUAL DO PAINEL”. Ele força a IA a mapear o que não é código antes de escrever código.

Ela admitiu o que não conseguia testar

Sobre o gatilho que cria o perfil quando alguém se cadastra:

⚠️ Não consigo verificar sem criar um usuário de verdade. Ele só dispara num cadastro real, e isso envia email e cria conta. Vou deixar isso como o primeiro teste depois de implementar.

Isso é o comportamento que você quer. O arquivo de regras do capítulo 1 pede que ela diga as suposições em vez de escolher em silêncio, e “eu não consigo confirmar isso” é a suposição mais valiosa que existe.

Uma IA sem essa regra teria escrito “✅ verificado” e seguido.

As perguntas que ela fez

Cinco pontos de decisão. Três valem pra qualquer app:

Como o código de 6 dígitos aparece na tela? Um campo único e grande, ou seis quadradinhos separados, como app de banco? Ela avisou: “os quadradinhos ficam mais bonitos e dão mais trabalho”.

O que acontece ao tocar em Google e Apple, já que estão inativos? Não fazer nada, ou mostrar “em breve”? Ela justificou a pergunta: “botão que não responde costuma parecer defeito”. Escolhi o aviso.

Qual o tamanho mínimo de senha? O padrão do serviço é 6 caracteres. Mantive.

Sobre a senha, uma armadilha que descobri semanas depois e que vale te poupar: esse mínimo existe em dois lugares. Um no seu código, outro na configuração do serviço. Mudar só o do código não muda a regra de verdade, o servidor continua aceitando o que ele quiser. Se for mexer, mexa nos dois.

O dia acabou no meio

Enquanto a IA verificava o ambiente, bateu o limite de uso da minha conta:

“You’ve hit your session limit.”

Esperei, voltei e escrevi “continue”. Ela retomou de onde parou, sem perder nada.

Vale saber que isso acontece, principalmente nos capítulos longos. Não é erro, e não estraga o trabalho, o histórico da conversa fica salvo.

5. Armadilhas

Mandar executar antes de resolver o painel. Se o email ainda estiver configurado pra mandar link, a tela de código vai ficar esperando pra sempre e você vai procurar bug no lugar errado.

Não testar com um email de verdade. É a única forma de saber se funciona. Use um email seu que você consiga abrir na hora.

Testar só o caminho feliz. Depois que o cadastro funcionar, teste os erros de propósito: digite o código errado, espere ele vencer, erre a senha no login, peça pra reenviar duas vezes seguidas. É aí que aparecem as telas que ninguém escreveu.

Esquecer de testar fechar e abrir o app. A pessoa entrou; feche o app, abra de novo. Ela tem que continuar dentro. Se voltar pra tela de boas-vindas, a sessão não está sendo guardada.

6. Terminou quando

• Você criou uma conta de verdade, com um email seu.
• O email chegou com um código, não com um link.
• Digitou o código e entrou no app.
• Fechou o app, abriu de novo, e continuou logado.
• Testou errar a senha e apareceu uma mensagem clara, não um erro técnico.
• Testou “esqueci minha senha” inteiro, até trocar a senha e entrar.
• Saiu da conta e voltou pra tela de boas-vindas.
• No painel do serviço, o seu usuário aparece na lista de contas e o perfil dele foi criado na tabela de perfis.

O último item é o que confirma que o gatilho funciona. Se a conta existe mas o perfil não, é isso que está quebrado.

Resumo do capítulo

O que você vai fazer neste passo

Criar as telas de perguntas que a pessoa responde quando entra no app pela primeira vez, o onboarding.

Uma pergunta (ou um grupinho de perguntas) por tela, com barra de progresso e botão de voltar. No fim, o app sabe quem é aquela pessoa e consegue mostrar conteúdo que faz sentido pra ela.

Por que isso importa

O onboarding é a única parte do app onde você pode pedir informação sem que pareça chatice. Depois disso, cada pergunta nova incomoda.

Mas ele tem um risco: é fácil perguntar coisa demais. Toda pergunta a mais é gente a menos que termina o cadastro. Por isso o prompt tem uma regra dura, toda pergunta precisa provar que serve pra alguma coisa, ou é cortada.

Quando fazer

Depois do login funcionando. E leia a próxima seção antes de rodar o prompt.

1. Uma decisão que você precisa tomar antes

Existem duas ordens possíveis, e o curso escolhe uma delas por você. Eu escolhi a outra, e recomendo a outra.

Opção A, perguntas primeiro, cadastro depois. A pessoa responde tudo, vê um resultado, e só então cria a conta. A ideia é que ela se engaja antes de ter que dar email.

Opção B, cadastro primeiro, perguntas depois. A pessoa cria a conta, confirma o código, e aí responde.

A opção A tem um custo escondido que ninguém conta: como a conta ainda não existe, você não tem onde guardar as respostas. Elas ficam no celular, e você precisa escrever um código extra que pega tudo o que está no aparelho e move pro banco depois do cadastro.

Isso significa: dado em dois lugares, código de transferência pra escrever e testar, e um caso feio pra resolver, a pessoa responde tudo e o cadastro falha no fim.

E tem uma coisa que a opção A simplesmente não consegue fazer bem: pedir foto. Foto vai pra um espaço privado, separado por usuário. Sem conta, não existe usuário, então a foto teria que ficar no celular e subir depois, o que é mais código ainda.

Escolha a opção B se o seu onboarding pede foto. O prompt abaixo já está escrito pra ela.

2. O prompt (cole isso)

Crie o onboarding do [NOME DO APP]. Use o CLAUDE.md como contrato.

ANTES DE QUALQUER COISA, verifica:
- O design system e os componentes base existem?
- O login já existe e funciona?
- O banco tem onde guardar os dados que o onboarding vai gerar, ou faltam
  colunas?
- Já existe alguma marca de "onboarding concluído"? Sem ela, não dá pra
  saber quem já terminou.
Se algo faltar, me guia passo a passo em português comum, sem termo técnico.

ORDEM DO FLUXO: a conta é criada ANTES do onboarding. A pessoa se cadastra,
confirma o código, e só então responde as perguntas. Cada resposta grava
direto no banco, sem passar pelo armazenamento do aparelho.
Se isso contradisser algo que já está no CLAUDE.md ou já construído, PARE e
me avise antes de planejar.

PRINCÍPIOS (não-negociáveis):
1. Toda pergunta personaliza o app OU prepara a cobrança. Cruze cada
   pergunta com quem consome o dado. Se alguma não serve pra nada, me
   avise e proponha cortar, não construa por construir.
2. O que a pessoa responde não pode ser algo que o app deveria decidir.
   Se uma pergunta deixa a pessoa escolher o próprio limite, benefício ou
   privilégio, ela está errada. Aponte.
3. Progresso salvo a cada passo. Fechou no meio, volta de onde parou.
4. Conclusão à prova de repetição: quem já terminou nunca mais vê o
   onboarding, mesmo forçando o endereço da tela na mão.

ESCOPO:
- Aqui: a sequência de telas, as perguntas, a gravação, a barra de
  progresso, o botão voltar, e o direcionamento pro app no fim.
- Fora: cobrança, notificações reais, e [o que mais for fase futura].

REFERÊNCIA VISUAL (se tiver):
Use a imagem [nome do arquivo] como fonte da verdade do visual. Extraia
cada tela na ordem em que aparecem e replique o layout fielmente. Me diga
o que a imagem NÃO deixa claro, e leve isso pros PONTOS DE DECISÃO.

SEQUÊNCIA DE TELAS
[liste em ordem, ou escreva "extraia do mockup"]

PERGUNTAS
[liste cada pergunta e suas opções, ou escreva "extraia do mockup"]

O USO DE CADA RESPOSTA
Pra cada resposta, diga onde no app ela é usada. Se não souber o consumidor
de alguma, me pergunte em vez de adivinhar.

ANTES DE CRIAR ARQUIVOS, me entrega:

1. RESUMO EM PRODUTO. Em português comum, o que acontece em cada caso:
   pessoa nova, pessoa que volta, fechou no meio, terminou, e quem já tinha
   conta antes.

2. PONTOS DE DECISÃO em português comum.

3. PLANO TÉCNICO:
   a. Uma tabela: cada resposta, e quem consome ela no app.
   b. Onde cada dado é guardado.
   c. Colunas que faltam no banco, e a alteração proposta.

Espera minha aprovação antes de criar arquivos.

Como preencher

3. O que aconteceu comigo

Este foi o passo em que o arquivo de regras do capítulo 1 se pagou inteiro.

A IA se recusou a seguir o prompt

O modelo do curso trazia, entre os princípios não-negociáveis, o item 3:

“O onboarding roda ANTES do cadastro: tudo no aparelho, migrado no signup.”

Colei do jeito que veio. A primeira frase da resposta foi:

“Antes de qualquer plano, preciso verificar o estado real. Um aviso já de saída: o item 3 dos seus princípios contradiz uma decisão que já está no CLAUDE.md.”

E depois, com as duas citações lado a lado:

“Não dá pra fazer os dois.”

Ela pegou porque o contrato existia. Sem o arquivo do capítulo 1, ela teria obedecido o prompt, construído a versão com transferência de dados, e eu só descobriria o conflito semanas depois, com o código já escrito.

E ela deu o argumento prático que fechou a discussão:

“A primeira tela do onboarding pede foto de perfil. O espaço de fotos é privado, com permissão por usuário, só dá pra enviar depois que a conta existe. Rodando antes do cadastro, a foto teria que ficar guardada no aparelho e subir só depois, que é justamente o trabalho extra que a decisão do CLAUDE.md evitava.”

Escolhi manter o cadastro primeiro. A resposta seguinte dela:

“Sua escolha tem uma consequência que preciso registrar: a seção PERSISTÊNCIA do seu pedido fica sem efeito, com a conta já criada, não há transferência; grava-se direto no banco.”

Uma seção inteira do prompt do curso virou letra morta. E foi bom.

Ela cortou duas perguntas minhas

O princípio 1 diz que toda pergunta precisa servir pra alguma coisa. Ela levou a sério, cruzou cada pergunta com quem usava o dado, e derrubou duas de nove.

“Quantos convites você tem?”, um seletor de 0 a 5 na quarta tela.

“Essa é a mais séria. O usuário escolhe quantos convites ele tem. Isso não personaliza nada: é o app que deveria conceder a cota, não a pessoa. Do jeito que está, qualquer um escolhe 5.”

E então a frase que fecha o caso:

“Isso também explica por que não existe coluna no banco: nunca houve como isso ser resposta.”

Eu tinha desenhado, no mockup, uma pergunta que entregava ao usuário o controle do próprio limite. Parecia uma pergunta. Era um furo.

“Qual sua cidade?”, primeira tela.

“O Feed calcula distância por coordenada de GPS, não por nome de cidade. Ninguém lê esse campo, e não há coluna.”

Cortada, trocada pelo pedido de permissão de localização, que é o dado que o app realmente usava.

Duas telas a menos, sem perder nada. Cada pergunta cortada é gente a mais terminando o cadastro.

Ela achou um problema fora do escopo

No meio dos pontos de decisão, isto:

“Existe um buraco sério de segurança, e ele encosta nesta fase. Hoje qualquer usuário pode, pelo próprio app, marcar-se como premium, a permissão de escrita libera todas as colunas do perfil. Isso contraria o que está no CLAUDE.md. É trabalho pequeno, mas está fora do que você pediu, me diga se entra ou fica pra depois.”

Repare no comportamento: achou, avisou, perguntou, não consertou sozinha. É exatamente o “reporte decisões fora do pedido” do capítulo 1.

Ela apontou uma contradição no meu próprio pedido

“Seu pedido diz ‘uma pergunta por tela’, mas os mockups que você aprovou agrupam. A tela 1 pede foto, nome e nascimento juntos. Vou manter o agrupamento dos mockups, porque já está construído e aprovado. Se quiser uma pergunta por tela de verdade, o onboarding vira 9 telas e é outro trabalho.”

E um detalhe pequeno que mostra atenção:

“A primeira tela do onboarding se chama ‘Criar conta’. Com a conta já criada antes, o nome ficou errado. Proponho renomear para ‘Sobre você’.”

A tela vazia honesta

O onboarding terminava mostrando quantos parceiros compatíveis existiam perto. Num app novo, esse número é zero.

“‘Sem dado inventado’ é regra sua, então não vou inventar número. Proponho um estado vazio honesto: ‘Você é dos primeiros por aqui, avisamos quando alguém compatível aparecer’. Funciona, mas é bom você saber que os primeiros usuários vão ver isso.”

Poderia ter escrito “127 pessoas compatíveis” e a tela ficaria linda. Ficaria mentindo.

4. Armadilhas

Perguntar o que o app deveria decidir. Foi meu erro com os convites. Teste simples: se a resposta dá à pessoa um limite, um benefício ou um privilégio, não é pergunta: é falha.

Perguntar sem saber quem usa a resposta. Se você não consegue dizer em qual tela aquele dado aparece, corte a pergunta. Você pode sempre perguntar depois.

Não salvar o progresso a cada passo. A pessoa fecha o app na quinta pergunta, volta, e tem que responder tudo de novo. Não volta.

Esquecer a marca de “terminou”. Sem ela, não tem como saber quem já respondeu, e o app fica mandando a pessoa pro onboarding pra sempre.

Deixar o número bonito falso na tela de resultado. Ele engana você, não o usuário. Você acha que está pronto e não está ligado em nada.

5. Terminou quando

• Você criou uma conta nova e passou pelo onboarding inteiro.
• Conferiu no painel do banco que cada resposta chegou lá.
• Fechou o app no meio, abriu de novo, e voltou de onde parou, com o que já tinha respondido preenchido.
• Terminou o onboarding, fechou o app, abriu, e foi direto pro app, sem passar pelas perguntas de novo.
• Fez login com uma conta que já tinha terminado antes: foi direto pro app.
• Para cada pergunta, você sabe dizer em qual tela do app aquela resposta aparece.
• Nenhuma pergunta deixa a pessoa escolher o próprio limite ou benefício.

Resumo do capítulo

O que você vai fazer neste passo

Trocar todo o conteúdo falso das telas por conteúdo de verdade, vindo do banco.

Até aqui suas telas mostram gente inventada, números redondos e listas cheias que não vieram de lugar nenhum. Depois deste passo, elas mostram o que existe de verdade, e ficam vazias quando não existe nada.

Por que isso importa

É o passo em que o app deixa de ser uma maquete.

E é o passo em que se decide se você vai sofrer depois. A IA vai criar uma camada de dados: um lugar só, por tipo de informação, que sabe buscar aquilo no banco. Todas as telas que precisam daquele dado usam o mesmo lugar.

Se cada tela buscar por conta própria, você vai ter a mesma busca escrita quatro vezes, e quando precisar mudar, vai esquecer uma. Eu passei por isso, e conto no fim do capítulo.

Quando fazer

Depois do onboarding. Agora existe dado de verdade no banco pra mostrar.

1. Uma coisa importante sobre este passo

Ele é dividido em dois capítulos, de propósito.

Este cobre as telas principais, onde a pessoa vê o que ela registrou no app. O próximo cobre perfil e configurações.

Parece burocracia, mas não é: junto, vira uma tarefa grande demais, e tarefa grande demais é onde a IA começa a errar. Duas tarefas médias saem melhor que uma gigante.

2. O prompt (cole isso)

Ligue as telas principais do app aos dados reais do banco. Use o CLAUDE.md
como contrato.

CONTEXTO: o banco já está pronto e o onboarding já grava dados no perfil. As
telas foram construídas na fase de design com dados de exemplo chumbados no
código. Agora elas passam a mostrar dados reais. Perfil e configurações são
uma etapa separada.

ANTES DE QUALQUER COISA, leia e mapeie (não presuma, descubra lendo):
- Leia as telas principais e liste, uma a uma, o que é dado falso e o que já
  é real.
- Leia o banco e veja de onde cada dado falso viria de verdade.
- Se algum dado que a tela mostra não tiver origem no banco, ou depender de
  algo que ainda ninguém cria, me reporta em português comum ANTES de mexer.
  Nunca invente dado nem coluna sem avisar.

PRINCÍPIOS (não-negociáveis):
- Zero dado falso. Dado real do banco, ou tela vazia com mensagem. Nunca
  valor inventado no código.
- Totais, médias e contagens são calculados do dado real, nunca escritos
  à mão.
- Uma camada de dados reutilizável por fonte de informação. Telas que usam o
  mesmo dado compartilham o mesmo lugar, não duplicam.
- Quatro estados em toda tela que busca dado: carregando, erro (com botão de
  tentar de novo), vazio (com mensagem) e sucesso.
- Toda tela recarrega ao voltar pra ela, e depois de uma edição, pra dado
  novo aparecer sem precisar fechar o app.
- Nenhum botão morto: todo botão, linha ou ícone ou funciona, ou é removido.
- Estilo sempre pelos tokens. Não escreva cor nem tamanho direto na tela.

ESCOPO:
- Aqui: as telas principais que exibem o que o usuário registra, mais editar
  e apagar esses itens, mais a camada de acesso a dados.
- Fora: perfil e configurações (etapa própria). Qualquer funcionalidade que
  CRIE dado novo por um fluxo próprio também é etapa própria.

ANTES DE MUDAR ARQUIVOS, me entrega:
1. RESUMO EM PRODUTO. Em português comum, o que cada tela mostra quando tem
   dado e quando está vazia.
2. PONTOS DE DECISÃO em português comum: dado que a tela mostra mas ninguém
   cria ainda, coluna que falta, tela que depende de coisa que não existe.
3. PLANO TÉCNICO:
   a. Tela por tela: o que era falso e de onde o dado real vem.
   b. As camadas de dados que vai criar e quem reusa cada uma.
   c. Colunas que faltam, e a alteração proposta.
   d. Onde cada estado (carregando, erro, vazio) entra.

Espera minha aprovação antes de mudar arquivos.

Como preencher

Nada. Vai inteiro.

3. O que esperar da IA

Ela vai ler cada tela e te devolver um inventário: o que era falso, de onde vem de verdade.

Espere descobrir buracos. É normal, e é bom. Telas desenhadas por um gerador de imagem quase sempre mostram alguma coisa que ninguém criou ainda, uma nota, um contador, um selo. A IA vai apontar cada uma e perguntar o que fazer.

Três respostas possíveis pra cada buraco, e vale decidir na hora:

• construir agora (se for simples e essencial)
• esconder a parte da tela até a funcionalidade existir
• deixar como está, sabendo que fica vazio

O que não vale é a quarta opção: deixar o número falso lá.

4. Os quatro estados (a parte que todo mundo esquece)

Este é o conceito mais útil deste capítulo, e vale entender antes de rodar o prompt.

Toda tela que busca dado pode estar em quatro situações:

Quase todo mundo constrói só o quarto. O prompt obriga os quatro.

O estado vazio é o mais importante e o mais esquecido. Todo usuário novo vê ele primeiro, antes de ver qualquer conteúdo. É literalmente a primeira impressão do seu app funcionando.

5. O que aconteceu comigo

O que a IA encontrou

Rodei o prompt em 30 de julho, à noite. Ela leu as telas uma por uma antes de propor qualquer coisa, que é o que o “não presuma, descubra lendo” pede.

O padrão que apareceu: as telas mostravam mais coisa do que o banco tinha. Não por erro, por causa do mockup. O gerador de imagem tinha preenchido as telas com números convincentes, e vários deles não vinham de lugar nenhum.

Isso é a continuação direta do capítulo 4, onde a IA já tinha marcado “avaliação” e “seguidores” como o campo existe, o mecanismo é hipótese. Aqui a conta chegou: as telas mostravam esses números, e ninguém os criava.

O erro que eu cometi neste capítulo

Eu deixei a camada de dados se espalhar.

O prompt diz, com todas as letras: “telas que usam o mesmo dado compartilham o mesmo lugar, não duplicam”. Nem todas as telas seguiram isso, algumas buscaram por conta própria.

O resultado apareceu uma semana depois, numa revisão de código: a mesma busca de treinos estava escrita três vezes, em três telas diferentes. Cada uma buscando por si, cada uma com a chance de ficar desatualizada em relação às outras.

Consertar foi rápido: virou um lugar só, e as três telas passaram a ler dali. Mas foi trabalho que não precisava existir.

Como evitar: quando a IA te mostrar o plano, procure a lista de camadas de dados e conte. Se duas telas mostram a mesma coisa e aparecem em camadas diferentes, pergunte por quê antes de aprovar.

O botão morto

Um princípio do prompt que rendeu mais do que eu esperava: “nenhum botão morto”.

O mockup tinha ícones que eu nunca tinha pensado em fazer funcionar, um funil de filtro, um sino de notificação. A IA listou cada um e perguntou: isso vai funcionar agora, ou eu removo?

Botão que não faz nada é pior que botão que não existe. A pessoa toca, não acontece nada, e ela conclui que o app está quebrado.

6. Armadilhas

Deixar um número falso “só por enquanto”. Não existe por enquanto. Você esquece que ele é falso, mostra o app pra alguém, e a pessoa pergunta sobre aquele número.

Pular o estado vazio. É o que todo usuário novo vê primeiro. Escreva uma mensagem de verdade, não “Nenhum resultado”.

Aceitar que cada tela busque sozinha. Parece mais simples na hora e é. O preço vem depois, quando você muda uma regra e esquece de mudar nas outras.

Testar só com a sua conta cheia de dados. Crie uma conta nova, do zero, e navegue por tudo. É a única forma de ver os estados vazios que os seus usuários vão ver.

7. Terminou quando

• Você procurou por nomes inventados no código (tipo “Mariana”, “Rafael”) e não achou nenhum.
• Criou uma conta nova e navegou por todas as telas: todas mostram estado vazio com mensagem, nenhuma parece quebrada.
• Registrou alguma coisa e ela apareceu na tela sem você fechar o app.
• Editou e apagou um item, e a tela refletiu na hora.
• Desligou a internet e abriu uma tela: apareceu erro com botão de tentar de novo, não tela branca.
• Tocou em todos os botões e ícones. Nenhum ficou sem resposta.
• Os totais e contadores batem com o que existe de verdade no banco.

Resumo do capítulo

⚠️ Este é o único capítulo do livro em que eu não segui o próprio prompt. Construí essas telas por conta, sem usar o modelo. Conto no fim o que isso custou, e é justamente por isso que este capítulo existe.

O que você vai fazer neste passo

Ligar as telas de perfil e configurações aos dados de verdade.

O perfil passa a mostrar o nome, a foto e as respostas que a pessoa deu no onboarding, e deixa ela editar tudo isso. As configurações param de ser uma lista de opções decorativas e passam a funcionar.

Por que isso importa

É a única parte do app onde a pessoa conserta o que ela mesma errou. Digitou o nome errado no cadastro, escolheu o objetivo errado, quer trocar a foto: é aqui.

E tem um detalhe que passa despercebido: as configurações são onde ficam as opções que ainda não existem. Assinatura, notificações, idioma, tudo aparece aqui antes de funcionar. Decidir o que fazer com essas opções enquanto elas não existem é metade do trabalho deste capítulo.

Quando fazer

Logo depois do capítulo anterior, enquanto o assunto ainda está fresco.

1. O prompt (cole isso)

Ligue as telas de perfil e configurações aos dados reais do banco. Use o
CLAUDE.md como contrato.

CONTEXTO: o banco já está pronto e o onboarding já coletou dados do perfil.
Essas telas foram construídas com dados de exemplo e com opções que ainda não
fazem nada. As telas principais são etapa separada, já feita.

ANTES DE QUALQUER COISA, leia e mapeie (não presuma, descubra lendo):
- Leia as telas de perfil e configurações e liste, uma a uma: o que é dado
  falso, o que já é real, e CADA botão, linha ou opção que existe.
- Leia o que o onboarding coletou. Esses dados devem aparecer aqui e ser
  editáveis.
- Pra cada opção das configurações, veja se ela tem como funcionar hoje ou se
  depende de algo que ainda não existe.
- Se alguma opção mostrar algo sem origem no banco, ou depender de coisa que
  não existe, me reporta em português comum ANTES de mexer.

PRINCÍPIOS (não-negociáveis):
- Zero dado falso. Nome, foto e dados do usuário vêm do banco.
- Reuse a camada de dados que já existe. Se as telas principais já leem o
  perfil, use o mesmo lugar, não crie outro.
- Quatro estados onde busca dado: carregando, erro (com tentar de novo),
  vazio e sucesso.
- Editar um dado salva no banco na hora, e a tela reflete a mudança.
- Nenhuma opção morta: toda opção ou funciona, ou é removida, ou, se
  depende de coisa futura, você me pergunta o que fazer com ela.
- Estilo sempre pelos tokens.

ESCOPO:
- Aqui: mostrar e editar os dados da conta, e ligar as opções que já dá pra
  ligar (sair da conta, preferências salvas no banco, links legais, suporte).
- Mostrar a foto que já existir entra aqui. SUBIR uma foto nova é outra
  coisa: me pergunte se entra agora ou fica pra depois.
- Fora: as funcionalidades que essas opções abrem mas ainda não existem
  (assinatura, notificações). Aqui a gente só decide o que mostrar
  enquanto elas não existem.

ANTES DE MUDAR ARQUIVOS, me entrega:
1. RESUMO EM PRODUTO. Em português comum: o que o perfil mostra, o que dá
   pra editar, e o que acontece em cada opção das configurações.
2. PONTOS DE DECISÃO em português comum: se o envio de foto entra agora ou
   depois; o que fazer com as opções que dependem de coisa que não existe
   (esconder, desabilitar, ou avisar "em breve"); dado que falta.
3. PLANO TÉCNICO:
   a. De onde vem cada dado do perfil e como a edição salva.
   b. As camadas de dados que vai criar ou reusar.
   c. Opção por opção das configurações: o que faz cada uma.
   d. Colunas que faltam, e a alteração proposta.

Espera minha aprovação antes de mudar arquivos.

Como preencher

Nada. Vai inteiro.

2. A decisão do capítulo: o que fazer com o que não existe

A IA vai te dar uma lista de opções que não têm como funcionar ainda. Você tem três saídas, e cada uma serve pra um caso:

Esconder. A opção some da tela até a funcionalidade existir. Melhor quando falta muito tempo, ou quando você não tem certeza se vai construir.

Desabilitar. A opção aparece apagada, sem resposta ao toque. Evite, parece defeito, e a pessoa fica tentando.

Avisar “em breve”. A opção aparece normal, e ao tocar mostra um aviso. Melhor quando falta pouco, ou quando você quer que a pessoa saiba que aquilo vem aí.

Minha recomendação: esconder por padrão, “em breve” para uma ou duas coisas que você quer anunciar. Uma tela de configurações cheia de “em breve” parece um app inacabado, porque é.

⚠️ E uma coisa que só descobri semanas depois, do jeito difícil: esconder uma opção da tela não desliga o dado no banco.

Se alguém já tinha ligado aquilo antes de você esconder, continua ligado, e a pessoa não tem mais como desligar, porque o controle sumiu. Ela fica presa num estado que não consegue mudar.

Aconteceu comigo duas vezes, com o mesmo formato. Toda vez que esconder uma opção, decida explicitamente: o app ignora o valor que já está lá, ou zera pra todo mundo? Não decidir é escolher a pior das duas.

3. O que aconteceu comigo

Eu pulei este prompt

Não usei o modelo. Construí Configurações e Editar Perfil direto, pedindo à IA o que eu queria, tela por tela, sem o mapeamento que este prompt obriga.

Funcionou. As telas ficaram boas e estão no app até hoje.

O que apareceu no mesmo dia

Naquela mesma tarde, rodei uma revisão de código no projeto inteiro. Ela apontou uma lista de duplicação espalhada pelo app:

• a mesma busca de treinos escrita em três telas
• as listas de opções (objetivo, nível, modalidade) copiadas em até seis arquivos
• a regra de tamanho mínimo de senha declarada em três lugares
• o cabeçalho com botão de voltar reescrito em 37 telas, em dois estilos visuais diferentes competindo entre si

Nada disso estava quebrado. Tudo funcionava. Só era caro de mudar.

Não vou dizer que pular o prompt causou tudo isso, parte já vinha de antes, e parte é de telas que este capítulo nem cobre. Mas repare no que os princípios deste prompt dizem: “reuse a camada que já existe, não crie outro”, “liste CADA botão, linha ou opção”. São exatamente a defesa contra essa classe de problema. E as telas de configuração estavam no meio da lista, a senha duplicada, por exemplo, mora em três telas de configuração.

O prompt força um inventário antes de escrever. Eu não fiz o inventário.

Quanto custou consertar

Fui pagar isso 22 dias depois, num dia inteiro dedicado só a isso. O resultado:

830 linhas de código deletadas, sem o app perder nada.

E teve uma decisão desconfortável no meio: os 37 cabeçalhos estavam em dois estilos visuais diferentes, e eu tive que escolher um. Escolhi o das telas mais novas, o que significa que 31 telas mudaram de aparência de uma vez. Se eu tivesse unificado desde o começo, essa escolha teria custado nada.

A lição

Duplicação não dói quando nasce. Dói quando você precisa mudar a coisa duplicada, e descobre que precisa mudar em seis lugares, e que esqueceu um.

O prompt deste capítulo não é burocracia. Ele é meia hora agora pra evitar um dia depois.

4. Armadilhas

Criar uma segunda camada de dados pro perfil. As telas principais já leem o perfil. Reuse. Se a IA propuser criar outra, pergunte por quê.

Deixar o botão de sair da conta sem confirmação. Toque errado, sessão perdida. Peça confirmação.

Salvar só ao sair da tela. Se a pessoa editar e o app fechar antes de salvar, ela perde e não sabe. Salve na hora.

Esconder opção sem decidir o que fazer com quem já tinha ligado. Explicado acima. É o erro que eu cometi duas vezes.

Deixar a tela de configurações virar depósito de “em breve”. Se tem mais de duas, esconda o resto.

5. Terminou quando

• O perfil mostra o nome, a foto e as respostas do onboarding, todos reais.
• Você editou cada campo e conferiu no painel do banco que salvou.
• Saiu da tela e voltou: a mudança continua lá.
• Tocou em todas as opções das configurações. Nenhuma ficou sem resposta.
• Para cada opção que depende de coisa futura, você decidiu conscientemente entre esconder e “em breve”.
• Para cada opção escondida, você decidiu o que acontece com quem já tinha ligado antes.
• Sair da conta funciona e pede confirmação.
• Você não criou nenhuma camada de dados nova pro que já era lido antes.

Resumo do capítulo

O que você vai fazer neste passo

Colocar uma funcionalidade de IA dentro do seu app, algo que a pessoa usa e que chama um modelo por trás.

Não é a IA que escreve o seu código (essa você já vem usando desde o capítulo 1). É a IA que vira parte do produto: sugerir um texto, entender uma foto, montar um plano.

Por que isso importa

É a primeira vez no livro que o seu app fala com um serviço de fora. Isso traz três problemas novos que nenhum capítulo anterior teve:

Custo. Cada uso gasta dinheiro (ou cota grátis). Se alguém usar mil vezes, você paga mil vezes.

Uma senha que não pode vazar. O serviço de IA te dá uma chave de acesso. Se ela for parar dentro do aplicativo, qualquer pessoa consegue extrair, e gastar no seu nome.

Falha de fora. O serviço pode estar fora do ar, demorar, ou não entender o que mandaram. Seu app precisa saber o que fazer nos três casos.

A regra que resolve os três

A chave de IA nunca vai dentro do aplicativo.

Em vez do app chamar a IA direto, ele chama um pedacinho de código que roda no servidor. Esse pedacinho tem a chave, chama a IA, e devolve só a resposta.

Assim: a chave fica fora do alcance de todo mundo, e o servidor pode contar quantas vezes cada pessoa usou e cortar quando passar do limite.

Essa regra já está no seu arquivo do capítulo 1. Este capítulo é onde ela é usada pela primeira vez.

1. ANTES de rodar o prompt: teste o modelo

Este é o aviso mais valioso do capítulo, e ele vem de um erro meu.

Os serviços de IA têm vários modelos, com nomes parecidos. A cota grátis pode ser zero para um modelo específico, mesmo com a sua chave funcionando perfeitamente para os outros.

Você não descobre isso codando. Descobre quando o app já está pronto e a funcionalidade dá erro pra todo mundo.

Faça isto antes:

1. Entre no site de testes do provedor (todo grande tem um “playground”).
2. Rode uma pergunta qualquer no modelo exato que você pretende usar.
3. Se funcionar, procure o botão “Get code” ou equivalente e copie o nome exato do modelo. Não digite de memória, não deduza pelo padrão do nome.

Leva cinco minutos e evita uma tarde de debug.

2. O prompt (cole isso)

⚠️ Este prompt tem muitos colchetes, e todos precisam ser preenchidos. Explico o motivo logo depois.

Crie a feature de [O QUE O USUÁRIO FAZ] com IA no [NOME DO APP]. Use o
CLAUDE.md como contrato.

ANTES DE QUALQUER COISA, leia e verifica:
- Leia [A TELA ONDE A FEATURE COMEÇA] e o banco.
- O .env tem as variáveis reais?
- A tabela [TABELA PRINCIPAL] tem onde guardar o que a IA devolve? Se faltar
  coluna, me reporta.
- A chave do provedor de IA NÃO vai no app: ela é secret do servidor.
  Confirme isso no plano.
- Mapeie TUDO que a feature exige FORA deste código (conta no provedor,
  chave, secret no painel, publicação da função, permissão de sistema).
  Liste cada item como FEITO ou PENDENTE. Não presuma nada como feito: se
  não dá pra verificar daqui, marque como pendente e me pergunte.

PRINCÍPIOS (não-negociáveis):
- A chamada à IA passa SÓ pelo servidor. Chave nunca no app.
- Zero dado falso. O que for salvo é a resposta real da IA.
- Indicador de espera enquanto processa, erro com botão de tentar de novo, e
  tratamento do caso em que a IA não consegue entender a entrada.
- Considere que eu NUNCA usei o painel do provedor de IA nem o do servidor.
  Toda instrução envolvendo painel tem que ser no nível "clique em tal
  botão, no menu tal, digite exatamente isso".
- Quando algo der erro, não chute: me diga onde encontrar a mensagem real e
  diagnostique pelo erro exato.

PROVEDOR DE IA: [SERVIÇO] com o modelo [NOME EXATO, copiado do playground].
Isole o provedor dentro do servidor pra ser fácil trocar depois.

COMPORTAMENTO:
- A IA recebe [A ENTRADA] e devolve: [CAMPO A CAMPO].
- A pessoa pode ajustar [O QUE É EDITÁVEL] antes de salvar.
- [O INSUMO ORIGINAL] fica guardado em [ONDE], ligado a [QUAL REGISTRO].

ESCOPO:
- Aqui: proponha você, a partir do COMPORTAMENTO acima, os passos do fluxo
  desta fase. Liste no plano pra eu aprovar.
- Fora: notificações, cobrança e limite grátis/pago.

ANTES DE CRIAR OU MUDAR ARQUIVOS, me entrega:

1. RESUMO EM PRODUTO. Em português comum, o que acontece quando: dá certo, a
   IA não entende a entrada, e a IA ou a internet falha.

2. PONTOS DE DECISÃO em português comum.

3. PLANO TÉCNICO. Inclua o CÓDIGO COMPLETO da função de servidor, pronto pra
   eu copiar e colar no painel, com: o pedido à IA já escrito dentro,
   resposta forçada em formato fixo, validação do que volta, e erros
   devolvidos como mensagem legível. A chave lida de variável de ambiente,
   nunca escrita no código.

4. MANUAL DE CONFIGURAÇÃO, passo a passo clicável, como se eu nunca tivesse
   visto essas plataformas:
   a. CRIAR A CHAVE no provedor: site exato, qual menu, qual botão, como a
      chave se parece, e o aviso de tratá-la como senha.
   b. GUARDAR A CHAVE no painel do servidor: caminho até a tela de secrets,
      o NOME EXATO da variável, e a regra de ouro: se a função já existia
      antes do secret, precisa publicar de novo.
   c. PUBLICAR A FUNÇÃO: qual opção escolher, o nome exato, onde colar,
      onde clicar.
   d. TESTAR: o teste mais simples pra saber se deu certo.
   e. SE DER ERRADO: onde ficam os registros de erro, e uma tabela dos erros
      mais prováveis. Inclua: secret com nome errado, função não republicada,
      chave inválida, e cota estourada, lembrando que cota às vezes é POR
      MODELO, e trocar o modelo pode resolver.
   f. QUANTO CUSTA: o que a camada grátis cobre, quando estoura, e quanto
      custa cada uso se precisar pagar.

Espera minha aprovação antes de criar ou mudar arquivos.

3. Sobre preencher os colchetes: uma história curta

Eu colei este prompt com todos os colchetes em branco. Do jeito que veio do curso, sem trocar nada.

A resposta:

“O prompt chegou com os campos entre colchetes ainda por preencher. Sem saber qual é a feature, eu estaria inventando o produto inteiro, então prefiro perguntar.”

Ela estava certa, e vale entender por quê, porque em outro capítulo deste livro eu deixei os colchetes em branco e funcionou.

No capítulo 3, o prompt pedia pra eu listar cada tela. Deixei em branco, e a IA listou sozinha, corretamente. A diferença: eu tinha anexado a imagem. A resposta existia em outro lugar, e ela foi buscar lá.

Aqui não havia imagem, não havia tela pronta, não havia nada. Só uma ideia na minha cabeça.

A regra: você pode deixar em branco o que a IA consegue descobrir olhando alguma coisa. Não pode deixar em branco o que só existe na sua cabeça.

4. Armadilhas

Colocar a chave dentro do app “só pra testar”. Ela fica no histórico do projeto pra sempre, mesmo depois de você tirar. Se acontecer, gere uma chave nova e apague a antiga no painel.

Não republicar a função depois de criar o secret. A função guarda as variáveis do momento em que foi publicada. Criou o secret depois? Publique de novo. É o erro nº 1 desta fase.

Confiar que a resposta vem no formato certo. Modelo de IA às vezes devolve texto a mais, ou um campo faltando. O prompt pede validação, não tire.

Não pensar no limite de uso. Sem limite, uma pessoa pode usar mil vezes num dia. Coloque um teto por usuário desde cedo. Eu coloquei depois, e é mais trabalho.

Registrar a resposta inteira do provedor pra “ver o que veio”. Parece inofensivo e é o erro mais perigoso do capítulo.

Serviços externos devolvem mais dado do que você pediu, não é raro vir email, telefone ou nome junto. E registro de servidor não tem desfazer: você não apaga uma linha depois de gravada, só espera a retenção vencer.

Aconteceu comigo, investigando outra coisa, com um registro temporário que rodou uma vez só. Por sorte contra um dado de teste, não de uma pessoa real. Se tivesse sido real, não teria como limpar.

Registre só os campos que a sua lógica usa. Nunca a resposta inteira.

5. Terminou quando

• Você testou o modelo no playground antes de codar, e copiou o nome exato.
• A funcionalidade funciona no app de verdade.
• Você procurou a chave de IA dentro do código do app e não achou.
• Testou com a internet desligada: apareceu erro com botão de tentar de novo.
• Testou mandando uma entrada que a IA não consegue processar: apareceu mensagem clara, não erro técnico.
• Sabe onde ficam os registros de erro do servidor e já abriu uma vez.
• Sabe quanto cobre a camada grátis e o que acontece quando estourar.
• Nenhum registro de servidor grava a resposta inteira do provedor.

Resumo do capítulo

O que você vai fazer neste passo

Fazer o app avisar a pessoa mesmo quando ela não está com ele aberto.

Dois tipos, e é importante não confundir:

O lembrete que a pessoa cria. Ela escolhe o horário e os dias, e o app avisa.

A regra que você define. “Se não abriu o app há 7 dias, mande um aviso.” A pessoa não configura isso, você define no código.

Por que isso importa

É o que faz a pessoa voltar. Um app sem notificação é um app que só existe quando alguém lembra dele.

Mas é também a forma mais rápida de perder um usuário. Notificação demais, ou na hora errada, e a pessoa desinstala, ou pior, desliga tudo e você nunca mais alcança ela.

Por isso o prompt tem regras de anti-spam obrigatórias.

1. Uma separação importante antes de começar

Existem duas tecnologias diferentes com o mesmo nome, e misturar as duas é o erro mais comum aqui.

Notificação agendada no celular. O app fala com o próprio aparelho: “me lembre disso amanhã às 7h”. O celular guarda e dispara sozinho, sem internet, sem servidor. É o que este capítulo cobre.

Notificação enviada de fora. Alguma coisa acontece no servidor, outra pessoa te mandou mensagem, alguém aceitou seu convite, e o servidor manda o aviso pro celular. Exige infraestrutura própria e não é este capítulo.

O prompt abaixo cobre só a primeira, de propósito. A segunda tem um capítulo próprio na Parte III.

⚠️ Importante: se a coisa que dispara o aviso acontece no celular da pessoa (passou do horário, sequência de dias, não abriu há uma semana), é a primeira. Se acontece por causa de outra pessoa, é a segunda. Não tente resolver a segunda com a primeira, não funciona.

2. O prompt (cole isso)

Crie a fase de notificações do [NOME DO APP]. Use o CLAUDE.md como contrato.

ANTES DE QUALQUER COISA, leia e verifica:
- O app já tem alguma base de notificação? Procure biblioteca instalada,
  camada de agendamento, telas de lembrete e pedido de permissão. Liste o
  que JÁ EXISTE e o que FALTA, e reuse o que existir, não reescreva.
- A permissão já é pedida em algum lugar? Em qual momento?
- Tem onde guardar as preferências do usuário? Se faltar, me reporta.
- Mapeie o que a fase exige fora do código (permissão do sistema, teste em
  celular de verdade). Liste cada item como FEITO ou PENDENTE.

TIPO TÉCNICO:
- Todas as notificações desta fase são agendadas PELO APP, no próprio
  celular: tanto as que o usuário cadastra quanto as que EU defino como
  regra no código. Nenhuma precisa de envio externo.
- Fica de fora o envio ao vivo, que exige servidor. Não construa nada disso
  agora, nem "pra deixar pronto".
- Se algo que eu pedi não funcionar desse jeito, NÃO improvise: me avise no
  plano e proponha a alternativa mais próxima.

PRINCÍPIOS (não-negociáveis):
- Permissão pedida no momento certo, junto de um valor pro usuário, nunca no
  susto. Negou? O app continua funcionando 100%, com um caminho claro pra
  reativar nas configurações.
- Anti-spam: no máximo [N] notificações por dia e nenhuma entre [HORA] e
  [HORA]. O usuário gerencia só os lembretes DELE; as regras de fábrica são
  configuração minha, no código.
- Toda notificação abre o app no lugar certo, não na tela inicial genérica.
- Agendamento real no sistema, testável no celular.

CATEGORIAS DESTA FASE:
1. LEMBRETE DO USUÁRIO: a pessoa cadastra horários e dias.
2. HÁBITO: lembrete diário se ainda não fez a ação principal do dia.
3. CONQUISTA: celebrar um marco.
4. REENGAJAMENTO: não abre há N dias, um aviso, reagendado a cada uso e
   cancelado quando ela volta.
5. RECUPERAÇÃO: começou um fluxo-chave e não terminou, aviso em N horas.
[apague as categorias que não quiser]

COMPORTAMENTO:
- Pra CADA categoria: quando dispara, o texto exato (título e corpo) e pra
  onde leva ao tocar.
- As regras de fábrica (2 a 5) não têm tela: horários, frequências e textos
  ficam num arquivo único e fácil de eu ajustar depois.
- Os TEXTOS são decisão minha: proponha 2 opções por notificação (uma neutra,
  uma no tom da marca) e eu escolho.
- Reagendamento correto: mudou horário, desligou ou reinstalou? O agendamento
  antigo é cancelado e refeito. Nunca notificação órfã ou duplicada.

ANTES DE CRIAR OU MUDAR ARQUIVOS, me entrega:
1. RESUMO EM PRODUTO. O que a pessoa recebe numa semana típica, o que recebe
   se sumir, e o que acontece se negar a permissão.
2. PONTOS DE DECISÃO: os textos (2 opções cada), os horários padrão, o limite
   diário e a janela de silêncio.
3. PLANO TÉCNICO:
   a. O que será reusado e o que será criado.
   b. Cada gatilho: o que agenda, quando reagenda, quando cancela.
   c. O arquivo único onde ficam as regras de fábrica.
   d. Diferenças entre iPhone e Android que afetam o comportamento.
   e. Como testar cada notificação sem esperar dias de verdade (modo de teste
      com minutos em vez de dias, removido antes de finalizar).
4. MANUAL DE TESTE NO CELULAR, passo a passo: como instalar a versão de teste
   no meu aparelho, o que fazer pra cada notificação disparar na hora, o que
   eu devo ver na tela bloqueada, como testar o caminho "permissão negada", e
   uma lista de "se não apareceu, provável causa", incluindo permissão
   desligada, modo não perturbe, e economia de bateria matando o app no
   Android.

Espera minha aprovação antes de criar ou mudar arquivos.

Como preencher

3. O aviso mais importante deste capítulo

Notificação não funciona no aplicativo de teste rápido.

Quando você roda o app em desenvolvimento, normalmente usa um aplicativo intermediário que carrega o seu código sem instalar nada de verdade. É prático, e funciona pra quase tudo.

Notificação não é quase tudo. Ela precisa de partes nativas do sistema que esse aplicativo intermediário não fornece. Você vai testar, não vai chegar nada, e vai procurar bug no seu código por horas.

Pra testar de verdade, é preciso gerar uma versão instalável do seu app e colocar no aparelho. É um processo à parte, que leva alguns minutos e é gratuito no Android.

Descubra isso agora, não depois de três horas procurando o bug.

4. As regras de anti-spam (a parte que salva o app)

Vale entender antes de rodar o prompt, porque é onde a maioria erra.

Limite por dia. Sem teto, cinco regras diferentes podem disparar no mesmo dia. Duas por dia é um bom começo.

Janela de silêncio. Nenhuma notificação entre a noite e a manhã. Não importa o que a regra diz.

Pedir permissão na hora certa. O momento errado é a abertura do app, quando a pessoa ainda não sabe o que ele faz. O certo é logo depois dela fazer algo que se beneficia do aviso. Quem nega na primeira tela quase nunca volta pra ligar.

Negou é negou. O app tem que funcionar 100% sem notificação, com um caminho claro nas configurações pra ligar depois.

Cancelar e reagendar direito. É o detalhe técnico que mais dá problema. A pessoa muda o horário do lembrete das 7h pras 8h: se o app agendar o novo sem cancelar o velho, ela recebe dois. Duas ou três mudanças depois, ela está sendo notificada cinco vezes e desliga tudo.

5. O que aconteceu comigo

O texto genérico que eu nunca personalizei

Uma das regras que criei foi a de reengajamento: sete dias sem abrir o app, e a pessoa recebe um aviso.

O texto que escolhi foi genérico, o mesmo pra todo mundo, falando de “seu parceiro de treino” no abstrato.

Semanas depois, percebi o óbvio: o app sabe o nome da pessoa com quem ela treinou por último. Usar o nome de verdade transforma um aviso genérico numa mensagem que parece escrita pra ela.

Continua na minha lista de coisas a fazer. A lição: quando for escolher os textos (o prompt vai te dar duas opções de cada), pergunte se o app não sabe alguma coisa que deixaria aquele texto pessoal. Quase sempre sabe.

O tipo que eu precisei e que este prompt não cobre

Metade das notificações que o meu app precisava não cabia nesta fase. Toda vez que alguém manda mensagem, aceita um convite ou começa a seguir você, o aviso nasce no servidor, por ação de outra pessoa, não tem como o seu celular adivinhar isso sozinho.

Construí essa parte depois, e ela tem capítulo próprio na Parte III.

O prompt está certo em separar as duas. Eu só menciono pra você não terminar este capítulo achando que notificação está resolvida, quando metade dela ainda não existe.

6. Armadilhas

Testar no aplicativo intermediário. Explicado acima. É a armadilha nº 1.

Pedir permissão na abertura do app. Você queima a única chance.

Não cancelar o agendamento antigo. Notificação duplicada é o caminho mais rápido pra pessoa desligar tudo.

Esquecer de tirar o modo de teste. Pra testar, a IA vai propor trocar “7 dias” por “2 minutos”. Se isso for pra versão final, seus usuários recebem aviso de reengajamento a cada dois minutos.

Não testar o caminho “permissão negada”. Boa parte das pessoas nega. Se o app quebrar ou ficar estranho pra elas, você perdeu essas pessoas.

7. Terminou quando

• Você gerou uma versão instalável e testou num celular de verdade.
• Criou um lembrete, e ele chegou no horário certo, com o app fechado.
• Tocou na notificação e o app abriu na tela certa, não na inicial.
• Mudou o horário de um lembrete e recebeu um aviso, não dois.
• Desligou um lembrete e ele parou de chegar.
• Negou a permissão e navegou pelo app inteiro: nada quebrou.
• Achou o caminho nas configurações pra ligar de novo depois de negar.
• Conferiu que o modo de teste (minutos em vez de dias) foi removido.
• Os textos estão no seu tom, não genéricos.

Resumo do capítulo

Não existe prompt do curso pra este capítulo. O curso te leva até o app funcionando. Ele não te leva até o app seguro. Este foi o maior bloco de trabalho do meu projeto inteiro, quatro dias, seis fases, dezenas de correções, e nenhuma aula falou dele.

O que você vai fazer neste passo

Descobrir tudo o que, no seu app, uma pessoa mal-intencionada consegue fazer e não deveria. Depois, fechar.

Por que isso importa

Seu app funciona. Você testa, tudo certo, as telas mostram o que devem mostrar.

O problema é que o app não é a única porta de entrada. Todo app que fala com um banco de dados na nuvem tem um endereço de internet, e qualquer pessoa com um pouco de conhecimento consegue falar com esse endereço direto, sem passar pelas suas telas.

Aí não existe mais “o botão não deixa”. Só existe o que o banco de dados permite. E se você nunca configurou isso, a resposta costuma ser: quase tudo.

Três exemplos do tipo de coisa que um app nessa situação costuma permitir, todos com o app funcionando perfeitamente na tela:

• Um usuário qualquer se marca como assinante pago, de graça.
• Alguém sem conta nenhuma baixa dados de perfil que deveriam exigir login.
• Um usuário se coloca dentro de um registro que pertence a outras duas pessoas.

Nenhuma dessas aparece na tela. Todas funcionam pela porta de trás, e é por isso que testar pelo app não encontra nenhuma delas.

Quando fazer

Antes de qualquer pessoa real usar o app. Não depois do lançamento.

Vale rodar de novo sempre que você adicionar uma feature grande.

1. A regra que organiza o capítulo: diagnosticar ≠ corrigir

O erro mais comum é pedir pra IA “achar e corrigir os problemas de segurança”. Ela vai fazer as duas coisas ao mesmo tempo, e você vai acabar com trinta mudanças no código sem entender nenhuma.

Faça em duas etapas separadas:

1. Diagnóstico. A IA só relata. Não muda uma vírgula. Você lê o relatório inteiro e entende o que cada coisa significa.
2. Correção. Uma fase de cada vez, em ordem de gravidade, com você aprovando cada uma.

Eu fiz assim: um diagnóstico, depois seis fases de correção em dias separados. Cada fase testada antes da seguinte.

2. Traduza a lista genérica pro seu app

Existe uma lista famosa dos dez problemas de segurança mais comuns (chamada OWASP Top 10). Pedir pra IA “rodar o OWASP Top 10” é uma boa ideia, mas não do jeito genérico.

Quando eu perguntei sobre isso, a resposta que recebi explica bem:

“O OWASP Top 10 foi desenhado pra apps web tradicionais com servidor próprio. Seu stack não tem servidor seu. Cada categoria precisa ser traduzida pro que realmente existe no projeto, senão a IA devolve uma lista de checkbox genérica que não bate com o código.”

Ou seja: sem tradução, você recebe um relatório bonito sobre problemas que o seu app nem pode ter, e nenhum sobre os que ele tem de verdade.

O prompt abaixo já faz essa tradução.

3. O truque que vale o capítulo inteiro

Antes de rodar o diagnóstico, encontre um problema você mesmo, um só, qualquer um, mesmo que pequeno. Depois, escreva ele dentro do prompt e peça pra IA confirmar se ainda existe.

Por quê: se ela relatar aquele problema com detalhe, você sabe que ela está lendo o seu código de verdade. Se ela devolver um relatório genérico e não mencionar aquilo, ela está repetindo lugar-comum.

É um teste de honestidade do relatório. Foi assim que eu soube que podia confiar no meu.

Não sabe achar um problema pra plantar? Comece por este: veja se existe algum arquivo que um usuário qualquer consegue baixar de outro usuário, foto de documento, selfie de verificação, comprovante. Esse é o furo mais comum, e foi exatamente o que eu plantei no meu.

4. O prompt do diagnóstico (cole isso)

Faça um diagnóstico de segurança do [NOME DO APP] mapeado no OWASP Top 10.
Use o CLAUDE.md como contrato.

ESTA FASE É SÓ DIAGNÓSTICO, não corrija nada ainda, só relate. A correção
vira uma fase separada, priorizada por gravidade, depois que eu ler.

CONTEXTO DO STACK (pra não aplicar OWASP genérico de app web tradicional):
[Descreva seu stack. Exemplo: "Não existe servidor próprio: é um app mobile
falando direto com um banco na nuvem que tem segurança por linha, login,
armazenamento de arquivos e funções de servidor. Não existe SQL escrito pelo
app. A superfície de ataque real é: regras de acesso mal escritas ou
faltando, segredos das funções de servidor, permissões de arquivo, e o que o
app consegue forjar numa chamada direta à API, sem passar pela tela."]

Para CADA categoria abaixo, procure o equivalente real neste projeto. Não
liste a categoria genérica se não achar nada concreto nela.

A01 QUEBRA DE CONTROLE DE ACESSO
- Releia TODAS as alterações do banco em ordem cronológica. Pra CADA tabela:
  a segurança por linha está ligada? As regras de leitura, escrita, alteração
  e exclusão fazem sentido, ou alguma ficou "liberado pra todo mundo" onde
  não devia?
- Toda tabela que o app conhece tem regra correspondente na versão mais
  recente que a cria ou altera?
- Confira especificamente: alguém consegue ler conversa de que não participa?
  Alterar registro de outra pessoa? Escrever em coluna que deveria ser só
  leitura (verificado, premium, nota média, contadores, cotas)?
- Confira as permissões de arquivo: um usuário qualquer consegue baixar
  arquivo de outro usuário?
- [PLANTE AQUI O PROBLEMA QUE VOCÊ JÁ CONHECE. Descreva onde ele está e
  peça: "isso já é um achado catalogado. Confirme se ainda está assim e
  relate como achado real, não hipotético."]

A02 DADOS SENSÍVEIS
- Algum dado sensível (localização exata, telefone, documento) é salvo ou
  trafega sem necessidade?
- O armazenamento local do celular guarda algo sensível além do token de
  sessão?

A03 INJEÇÃO
- Alguma função de servidor monta consulta juntando texto em vez de usar
  parâmetros?
- Algum campo de busca permite caractere especial que vaze mais dado do que
  deveria?

A04 FALHA DE DESIGN
- Alguma regra de negócio importante (limite grátis/pago, cotas, quem pode
  fazer o quê) é validada SÓ no app, sem espelho no servidor? O CLAUDE.md
  promete que isso é sempre validado no servidor. Confirme se é verdade em
  código, não só em intenção documentada.

A05 CONFIGURAÇÃO INCORRETA
- Alguma função de servidor está publicada sem exigir login quando deveria
  exigir?
- Alguma função do banco pode ser chamada por quem não tem conta?
- Algum arquivo de configuração com senha foi para o histórico do projeto?

A06 COMPONENTES DESATUALIZADOS
- Rode a checagem de vulnerabilidade das bibliotecas e relate o que aparecer.

A07 FALHAS DE AUTENTICAÇÃO
- O fluxo de login, código e recuperação de senha tem algum caminho que
  deixa entrar sem confirmar identidade?

A08 INTEGRIDADE
- Algum dado que só o servidor deveria escrever pode ser escrito pelo app?

A09 REGISTROS
- Alguma função de servidor grava a resposta inteira de um serviço externo,
  em vez de só os campos usados?

A10 CHAMADAS PARA FORA
- Alguma chamada externa usa endereço vindo do usuário?

FORMATO DO RELATÓRIO:
Pra cada achado: onde está (arquivo e linha), o que dá pra fazer com ele na
prática, a gravidade (crítico / alto / médio / baixo), e como corrigir.
Ordene por gravidade.

Se não achar nada em alguma categoria, diga "nada encontrado", não invente
achado pra preencher.

5. Depois do relatório: corrigir

Leia o relatório inteiro antes de corrigir nada. Depois, uma fase por vez:

Corrija o achado [NÚMERO] do diagnóstico: [descrição curta].

Só esse. Não toque em mais nada, mesmo que veja outro problema pelo caminho, se vir, me avise no fim, não corrija.

Me entregue o código do banco aberto na resposta, pronto pra eu copiar e
colar, com o passo a passo de onde clicar.

Depois de eu aplicar, me diga exatamente como testar que a correção
funcionou, incluindo como tentar fazer o ataque de novo pra confirmar que
agora falha.

O último parágrafo é o mais importante. Correção de segurança que você não testou tentando o ataque de novo não é correção: é esperança.

6. As cinco armadilhas que me pegaram

Estas não estavam em manual nenhum. Cada uma me custou pelo menos uma rodada de trabalho.

1. Fechar metade do buraco

Uma correção travou a criação de um registro forjado, mas deixou passar a alteração, o mesmo golpe funcionava mudando um registro em vez de criar um. Só foi pego numa releitura.

Sempre pergunte: e pela outra porta? Criar, alterar e apagar são três portas diferentes. Fechar uma não fecha as outras.

Foi o que me fez adotar uma regra: trabalho de segurança pede o modelo de IA mais forte disponível. É o tipo de erro sutil que o modelo mais leve deixa passar, e o custo de deixar passar é alto demais pra economizar aí.

2. Toda função nova nasce aberta

Descobri que o banco de dados, por padrão, libera toda função nova pra qualquer pessoa da internet, sem conta. Não é bug: é o comportamento normal, e quem não sabe nunca fecha.

No meu caso eram 34 funções nessa situação, e a faxina levou um dia. O tipo de estrago que isso permite: uma função criada pra montar a tela de perfil acaba respondendo pra quem nem se cadastrou, porque ninguém nunca disse que ela precisava de login.

Toda função nova precisa ser fechada explicitamente, na mesma alteração que a cria. Vale pra sempre, não só no dia da faxina.

3. Reescrever a partir da versão velha

Precisei mexer numa regra que já existia. Peguei a versão que achei primeiro no histórico, reescrevi, apliquei.

Apaguei em silêncio três correções feitas depois daquela versão. O banco não reclama: reescrever uma função zera tudo que você não repetir.

Três problemas voltaram de uma vez, e estavam rodando em produção. Só foram achados porque houve uma revisão antes de eu seguir em frente.

Antes de reescrever qualquer coisa que já existe, procure a versão mais recente, não a primeira que aparecer.

4. Esconder da tela não desliga no banco

Escondi um controle da tela pra um tipo de usuário. Quem já tinha ligado aquilo antes continuou com a coisa ligada, e sem nenhuma forma de desligar, porque o botão sumiu.

Aconteceu duas vezes, no mesmo formato. Na segunda, a pessoa ficava com o perfil cadeado, aparecendo numa lista mas sem mostrar nada, sem poder mudar.

Toda vez que esconder um controle, decida o que acontece com quem já tinha ligado. E procure todos os lugares que leem aquele valor, quase sempre é mais de um, e corrigir só um deixa um meio-estado pior que o problema original.

5. Coluna nova nasce sem permissão

O meu banco revoga a escrita por padrão e libera coluna por coluna. Isso é bom, é o que impede o usuário de se marcar como premium.

O efeito colateral: toda coluna nova precisa da liberação própria. Esqueci duas vezes. O sintoma engana: o formulário salva tudo normalmente, menos aquele campo, e nenhum erro aparece.

7. Terminou quando

• Você tem um relatório escrito, com os achados ordenados por gravidade.
• O achado que você plantou no prompt apareceu no relatório, com detalhe.
• Você entendeu o que cada achado permite na prática.
• Cada correção foi aplicada numa fase separada e testada antes da seguinte.
• Para cada correção, você tentou o ataque de novo e ele falhou.
• Toda tabela tem a segurança por linha ligada.
• Nenhuma coluna que só o servidor deveria escrever é gravável pelo app, teste tentando marcar-se como premium.
• Nenhuma função do banco é chamável por quem não tem conta.
• Nenhum usuário consegue baixar arquivo de outro usuário.
• As regras novas que você aprendeu foram escritas no arquivo do capítulo 1.

Resumo do capítulo

Não existe prompt do curso pra este capítulo.

O que você vai fazer neste passo

Pedir pra IA revisar o próprio trabalho dela, procurando não bug, mas código repetido, complicado à toa e caro de mudar depois.

Por que isso importa

Quando você constrói com IA, cada tela sai boa isoladamente. O problema aparece no conjunto: a IA não lembra que já resolveu aquele mesmo problema em outra tela, três dias atrás. Então ela resolve de novo.

Depois de umas trinta telas, você tem a mesma coisa escrita em seis lugares. Nada quebrado. Tudo funcionando. E cada mudança futura custa seis vezes mais, com a chance de você esquecer um.

É o tipo de problema que não dói hoje e dói muito daqui a um mês.

Quando fazer

A cada bloco grande de trabalho, não uma vez no fim.

Eu rodei a primeira revisão no segundo dia de projeto. Ela encontrou uma lista de duplicação que eu levei 22 dias pra pagar. Se eu tivesse rodado mais vezes no meio, a lista nunca teria crescido tanto.

1. Duas revisões diferentes

Não confunda com o capítulo anterior:

As duas são necessárias. Nenhuma substitui a outra.

2. O prompt (cole isso)

Revise o código deste projeto procurando manutenção cara, não bugs.
Use o CLAUDE.md como contrato.

ESTA FASE É SÓ RELATÓRIO, não corrija nada. A correção vem depois, item por
item, com minha aprovação.

Procure especificamente:

1. CÓDIGO REPETIDO
   - A mesma busca de dado escrita em mais de um lugar.
   - A mesma lista de opções copiada em vários arquivos.
   - A mesma regra (limite, validação, formato) declarada em mais de um
     lugar.
   - O mesmo bloco visual (cabeçalho, card, linha de lista) reescrito em
     várias telas em vez de virar um componente.
   Pra cada um: quantas cópias existem, em quais arquivos, e o que acontece
   se eu mudar uma e esquecer as outras.

2. INCONSISTÊNCIA
   - Duas formas diferentes de fazer a mesma coisa convivendo no projeto.
   - Telas que não seguem o padrão que as outras seguem.
   Se achar dois padrões competindo, me diga QUANTAS telas usam cada um,
   preciso desse número pra decidir qual fica.

3. COMPLICAÇÃO DESNECESSÁRIA
   - Código que resolve um problema que o projeto não tem.
   - Abstração criada pra um uso só.
   - Condição encadeada que caberia numa tabela simples.

4. CONTROLE MORTO
   - Botão, tela ou função que não é usada por nada.

FORMATO DO RELATÓRIO:
Pra cada achado: onde está, quantas cópias, o custo de deixar como está, e o
esforço estimado pra corrigir (pequeno / médio / grande).

Ordene por: quanto custa deixar como está, do pior pro melhor.

NÃO inclua: preferência de estilo, opinião sobre nome de variável, ou
sugestão de reescrever algo que funciona e não está duplicado.

Se não achar nada em alguma categoria, diga "nada encontrado".

3. O que fazer com o relatório

Não corrija tudo de uma vez. E não corrija na hora.

O relatório é uma lista de dívida. Guarde ela no arquivo do capítulo 1, escrita, com data. Depois escolha:

• Corrija agora o que é pequeno e o que está crescendo (cada tela nova aumenta o problema).
• Anote pra depois o que é grande e estável.
• Descarte o que não vale, e escreva por que não vale, senão a próxima revisão sugere de novo.

Eu descartei um item da minha lista e anotei o motivo. Meses depois, quando bateu a tentação de “arrumar aquilo”, o motivo estava lá escrito.

4. O que aconteceu comigo

A primeira revisão, no segundo dia

Rodei cedo, e ela encontrou:

• a mesma busca de treinos escrita em 3 telas
• as listas de opções copiadas em até 6 arquivos
• a regra de tamanho mínimo de senha em 3 lugares
• o cabeçalho com botão de voltar reescrito em 37 telas

Nada quebrado. Tudo funcionando.

O que aconteceu por eu não corrigir na hora

Levei 22 dias pra pagar. Nesse tempo, o projeto cresceu, e a dívida cresceu junto. O cabeçalho que estava em algumas telas passou a estar em 37.

Quando fui unificar, descobri o pior: existiam dois estilos visuais diferentes de cabeçalho rodando em produção ao mesmo tempo, e ninguém tinha percebido. Um em 6 telas, outro em 31.

Tive que escolher um. Escolhi o das telas mais novas, o que significa que 31 telas mudaram de aparência de uma vez. Se eu tivesse unificado no segundo dia, essa escolha custaria nada.

Total daquele dia de faxina: 830 linhas de código deletadas, sem o app perder nenhuma funcionalidade.

O erro de contagem que quase me fez decidir errado

Detalhe que vale ouro: quando fui contar quantas telas usavam cada estilo de cabeçalho, minha primeira busca achou 16. Com base nesse número, o estilo minoritário parecia ser o majoritário.

A busca estava viciada, eu tinha procurado por um termo que só existia num dos dois estilos. Procurando por outra coisa, apareceram 38.

Se eu tivesse decidido com o primeiro número, teria escolhido o estilo errado e mudado a aparência das telas mais visitadas do app.

É por isso que o prompt acima manda a IA dizer quantas telas usam cada padrão. Número errado leva a decisão errada, e você não desconfia.

O que a revisão me poupou

Um item da lista era trocar um campo de texto por um componente padrão. Parecia óbvio.

A IA analisou e recomendou não fazer: o componente exigia duas coisas que aquela tela não tinha por desenho, e tinha altura fixa onde a tela precisava que crescesse. Trocar teria piorado.

Revisão boa também diz o que não mexer.

5. Armadilhas

Rodar só no fim do projeto. Aí a lista é grande demais pra encarar, e você não faz nada.

Corrigir tudo que a revisão sugere. Ela vai sugerir coisa que não vale. Você decide, não ela.

Corrigir sem anotar o que descartou. A próxima revisão sugere de novo, e você reavalia do zero.

Deixar a IA corrigir e revisar na mesma tarefa. Ela vai “corrigir” e “melhorar” coisas que você não pediu. Relatório primeiro, correção depois, item por item.

Confiar no primeiro número de uma contagem. Peça pra IA dizer como contou. Se a busca estiver viciada, o número engana.

6. Terminou quando

• Você tem um relatório escrito, ordenado por custo.
• A lista de dívida está anotada no arquivo do capítulo 1, com data.
• Os itens que estão crescendo (cada tela nova piora) foram corrigidos agora.
• Os itens descartados têm o motivo escrito.
• Nenhuma correção quebrou nada, você navegou pelo app depois.
• Você marcou no calendário quando vai rodar a próxima.

Resumo do capítulo

Não existe prompt do curso pra este capítulo. Ele só é necessário se duas pessoas interagem no seu app. Se o seu app é individual (um diário, uma calculadora, um controle pessoal), pode pular.

O que você vai fazer neste passo

Fazer a tela se atualizar sozinha quando o dado muda, sem a pessoa precisar sair e voltar, e sem precisar fechar o app.

Por que isso importa

Tem um problema que só aparece quando o app já está pronto, e é difícil de diagnosticar porque não parece um bug.

A pessoa abre a tela de mensagens. Alguém manda uma mensagem. A tela dela não muda. Ela sai, volta, e aí aparece.

Nada quebrou. O app funciona. Mas parece velho e sem vida, e a pessoa aprende a não confiar no que está vendo.

Quando fazer

Depois das telas ligadas nos dados reais (capítulos 7 e 8).

1. Os dois problemas diferentes (não confunda)

Este capítulo resolve dois problemas que parecem um só. Entender a diferença economiza muito tempo.

Problema 1: a tela não recarrega quando você volta pra ela

Você está na tela de perfil, vai pra outra aba, volta. O perfil mostra o dado de antes.

Causa: abas normalmente não são desmontadas quando você troca. Elas ficam vivas em segundo plano. Então o código que busca o dado, que roda “quando a tela é criada”, não roda de novo, porque ela nunca foi destruída.

Solução: buscar o dado quando a tela ganha foco, não quando ela é criada. É uma troca pequena no código e resolve o caso mais comum.

Vale pra todas as telas que buscam dado. Sem exceção.

Problema 2: o dado muda enquanto a pessoa está olhando

A pessoa está parada na tela de mensagens. Alguém manda uma mensagem agora. Nada acontece, porque ela não saiu e voltou.

Causa: ninguém avisou o app. O dado mudou no servidor, e o app não tem como adivinhar.

Solução: uma conexão aberta com o servidor, que empurra o aviso na hora.

Isso NÃO vale pra todas as telas. Explico já.

2. A regra que evita gastar à toa

A conexão do problema 2 custa. Todo serviço de banco na nuvem limita quantas conexões simultâneas o seu plano aguenta. Abrir uma em cada tela gasta esse limite sem retorno.

A regra:

Abra conexão em tempo real só onde outra pessoa pode mudar o dado enquanto você está olhando.

Na prática:

Nas telas de “não”, a solução do problema 1 já basta.

3. O prompt (cole isso)

Revise como as telas deste app buscam e atualizam dado. Use o CLAUDE.md como
contrato.

ESTA FASE É DIAGNÓSTICO PRIMEIRO. Me entregue o mapa antes de mudar nada.

PARTE 1, MAPEAMENTO
Liste TODAS as telas e camadas de dados do app. Pra cada uma:
a. Ela busca dado quando é criada, ou quando ganha foco?
b. Se eu sair pra outra aba e voltar, ela mostra dado atualizado?
c. O dado que ela mostra pode ser alterado por OUTRA PESSOA?
d. Se sim, ela tem alguma forma de saber disso sem eu sair e voltar?

PARTE 2, DIAGNÓSTICO
Aponte:
- Telas que buscam dado só na criação e ficam desatualizadas ao voltar.
- Telas onde outra pessoa muda o dado e não existe atualização ao vivo.
- Conexões ao vivo abertas onde SÓ o próprio usuário muda o dado: isso
  gasta o limite de conexões do plano sem retorno, e deve ser removido.

PRINCÍPIOS:
- Toda tela que busca dado recarrega ao ganhar foco. Sem exceção.
- Conexão ao vivo SÓ onde outra pessoa pode mudar o dado enquanto a tela
  está aberta. Em tela que só o dono edita, recarregar ao focar já resolve.
- Cada conexão precisa de um identificador único. Duas conexões com o mesmo
  nome derrubam uma à outra ou quebram o app.
- Toda conexão é fechada quando a tela sai. Conexão esquecida aberta vaza.

PARTE 3, PLANO
Depois que eu ler o diagnóstico, proponha as mudanças em ordem, começando
pelas telas mais visitadas. Uma de cada vez.

Me diga também: o banco precisa de alguma configuração pra publicar essas
mudanças ao vivo? Se precisar, me guia passo a passo no painel.

Espera minha aprovação antes de mudar arquivos.

4. O que aconteceu comigo

O erro que quase ninguém encontra sozinho

O meu app tinha o código de tempo real escrito e correto. As telas estavam preparadas pra receber os avisos. Só que os avisos nunca chegavam.

O motivo: o banco de dados precisa ser configurado pra publicar as mudanças de cada tabela. Sem essa configuração, o código fica escutando um canal onde ninguém fala.

Não dá erro. Não aparece nada no registro. Simplesmente não funciona, e você procura o problema no lugar errado, no seu código, que estava certo o tempo todo.

É a última pergunta do prompt acima, e é por isso que ela está lá.

O crash que aparecia só às vezes

Um dia o app começou a fechar sozinho ao abrir uma conversa. Mas só às vezes, quando você abria a mesma conversa duas vezes seguidas.

Causa: duas conexões com o mesmo nome. A tela abria uma conexão, e ao reabrir sem ter fechado a anterior, o app tentava abrir outra com o nome idêntico.

O conserto foi dar um identificador único pra cada conexão. Depois desse, achei outra tela com o mesmo problema esperando pra acontecer, e padronizei todas.

Se o seu app fechar sozinho de forma intermitente numa tela que tem tempo real, suspeite disso primeiro.

A tela branca depois do cadastro

Terminei o onboarding e o app abriu uma tela branca. Nenhum erro na tela, nada.

Era o mesmo problema de conexão duplicada, num caminho diferente: o usuário recém-criado passava por uma sequência que abria a mesma conexão duas vezes.

Vale saber que o sintoma de conexão duplicada varia: às vezes é crash, às vezes é tela branca, às vezes é o dado simplesmente não chegar. A causa é a mesma.

5. Armadilhas

Achar que “recarregar ao voltar” resolve tudo. Resolve o problema 1, que é o mais comum. Não resolve o dado mudando enquanto a pessoa está parada olhando.

Abrir conexão ao vivo em tudo. Gasta o limite do seu plano em telas que só você edita. Quando precisar de verdade, não tem mais.

Esquecer de fechar a conexão quando a tela sai. Elas acumulam, e o app começa a ficar lento sem motivo aparente.

Não configurar o banco pra publicar. O código fica certo e nada funciona. É o erro mais frustrante do capítulo porque não dá nenhum sinal.

Repetir o nome da conexão. Crash intermitente, tela branca, ou silêncio. Três sintomas, uma causa.

6. Terminou quando

• Você tem o mapa de todas as telas e como cada uma busca dado.
• Toda tela recarrega ao voltar o foco: teste indo pra outra aba e voltando.
• Com dois aparelhos (ou duas contas em dois lugares), você mandou uma mensagem de um e ela apareceu no outro sem tocar em nada.
• Testou o mesmo com notificação e com o dado de perfil.
• Nenhuma tela que só o próprio usuário edita tem conexão ao vivo aberta.
• Abriu e fechou a mesma tela cinco vezes seguidas: o app não fechou nem travou.
• Confirmou no painel do banco que as tabelas certas estão publicando.

Resumo do capítulo

Não existe prompt do curso pra este capítulo. O prompt de notificações (capítulo 10) exclui isso de propósito: “fica de fora o envio ao vivo, que exige servidor: é outra fase”. Esta é a outra fase.

O que você vai fazer neste passo

Fazer o app avisar a pessoa quando outra pessoa faz alguma coisa: mandou mensagem, aceitou um convite, começou a te seguir.

Por que isso importa

O capítulo 10 resolveu os avisos que o celular consegue agendar sozinho: “me lembre amanhã às 7h”, “avise se eu não abrir o app em 7 dias”.

Mas metade das notificações de um app social não é assim. Quando alguém te manda uma mensagem, o seu celular não tem como adivinhar. A informação nasce no servidor.

Sem este capítulo, a pessoa só descobre que recebeu mensagem quando abre o app. O que significa que ela nunca abre o app.

Quando fazer

Depois do capítulo 10 e do capítulo 13. Este é o mais dependente de infraestrutura do livro inteiro.

1. Antes de tudo: você precisa de uma versão instalável

Igual ao capítulo 10, mas mais absoluto: isso não funciona no aplicativo de teste rápido. Nem um pouco.

Você precisa gerar uma versão instalável do app e colocar no aparelho. É gratuito no Android e não é difícil, mas leva um tempo na primeira vez.

Faça isso antes de começar o capítulo, não no meio.

2. Como funciona (em três frases)

1. Cada celular que instala o app recebe um endereço único e manda pro seu banco, guardado junto do perfil.
2. Quando algo acontece no banco (mensagem nova), um gatilho chama um pedacinho de código no servidor.
3. Esse código pega o endereço do celular do destinatário e pede pro serviço de entrega mandar o aviso.

O que você precisa construir: guardar o endereço, o gatilho, e o pedacinho de código.

3. A decisão de arquitetura que evita um problema sério

Existem duas formas de disparar o gatilho, e uma delas tem um problema que demora a aparecer.

Forma A, gatilho escrito direto no banco. Você escreve um comando que, ao inserir uma mensagem, chama a função. Parece o caminho natural.

O problema: pra chamar a função, esse comando precisa de uma senha de administrador do seu projeto. E como o comando é escrito num arquivo de alteração do banco, essa senha vai para o histórico do projeto, pra sempre. Mesmo que você tire depois, ela fica no histórico.

Forma B, gatilho configurado no painel. O mesmo efeito, só que a ligação é feita clicando no painel do serviço, não escrevendo em arquivo. A autenticação fica guardada fora do código, e nada sensível entra no histórico.

Use a forma B. É o que o prompt abaixo pede.

4. O prompt (cole isso)

Crie a fase de avisos enviados pelo servidor no [NOME DO APP]. Use o
CLAUDE.md como contrato.

CONTEXTO: os avisos agendados no próprio celular já existem. Esta fase cobre
só os que nascem de ação de OUTRA pessoa e precisam ser enviados de fora.

ANTES DE QUALQUER COISA, leia e verifica:
- Existe onde guardar o endereço de notificação de cada aparelho? Se não,
  me reporta.
- Já existe alguma função de servidor no projeto? Reuse o padrão dela.
- Mapeie TUDO que esta fase exige fora do código: conta no serviço de
  entrega, permissão do sistema, versão instalável do app, configuração no
  painel. Liste cada item como FEITO ou PENDENTE. Não presuma nada como
  feito.
- Considere que eu NUNCA configurei isso. Toda instrução de painel tem que
  ser "clique em tal botão, no menu tal, digite exatamente isso".

DECISÃO DE ARQUITETURA (não-negociável):
O disparo é configurado pelo PAINEL do serviço, não por comando escrito no
banco. Comando escrito no banco precisaria da chave de administrador dentro
de um arquivo de alteração, e essa chave iria pro histórico do projeto pra
sempre. A configuração pelo painel guarda a autenticação fora do código.
Se você discordar dessa escolha, me avise no plano em vez de improvisar.

PRINCÍPIOS (não-negociáveis):
- A função que envia precisa conferir um segredo próprio no cabeçalho da
  chamada, guardado como variável de ambiente. Sem isso, qualquer pessoa
  que descubra o endereço da função consegue disparar aviso pros seus
  usuários.
- Compare o segredo removendo espaços e quebras de linha dos dois lados.
  Painéis costumam aceitar texto colado com espaço invisível no fim.
- Aparelho sem endereço registrado, ou com endereço inválido, não pode
  derrubar o envio pros outros.
- A pessoa não recebe aviso de coisa que ela mesma fez.
- Respeita as preferências de notificação que já existem.
- Tocar no aviso abre o app na tela certa.

ESCOPO:
- Aqui: guardar o endereço do aparelho, o disparo, a função de envio, e os
  avisos de [LISTE OS EVENTOS: mensagem nova, convite aceito, etc.].
- Fora: campanhas de marketing e envio manual.

ANTES DE CRIAR OU MUDAR ARQUIVOS, me entrega:
1. RESUMO EM PRODUTO. O que a pessoa recebe, em que situação, e o que
   acontece se ela negou a permissão ou trocou de celular.
2. PONTOS DE DECISÃO em português comum.
3. PLANO TÉCNICO, com o CÓDIGO COMPLETO da função de envio, pronto pra eu
   colar no painel.
4. MANUAL DE CONFIGURAÇÃO passo a passo:
   a. Gerar a versão instalável e colocar no meu aparelho.
   b. Criar o segredo no painel, com o NOME EXATO da variável.
   c. Publicar a função, e se ela precisa ou não exigir login (esta
      específica é chamada pelo painel, não por um usuário logado).
   d. Configurar o disparo no painel: em qual menu, qual tabela, qual
      evento, qual endereço, e onde colar o segredo no cabeçalho.
   e. Testar de ponta a ponta com dois aparelhos ou duas contas.
   f. SE NÃO CHEGAR: onde ficam os registros da função, e uma tabela de
      erro provável → o que significa → o que fazer.

Espera minha aprovação antes de criar ou mudar arquivos.

5. O erro que você vai ter, e como reconhecer

Vou te poupar horas.

Sintoma: os avisos param de chegar. Todos, de uma vez. Não só um tipo, se mensagem parou, convite também parou, seguidor também.

Onde olhar: nos registros da função de envio, toda chamada aparece como erro de autorização.

A causa quase sempre é a mesma: o segredo guardado na variável de ambiente e o segredo colado no painel do disparo não são idênticos, mesmo que os dois pareçam iguais na tela.

O motivo é bobo e cruel: o campo do painel costuma aceitar texto de várias linhas. Ao colar, sobra um espaço ou uma quebra de linha invisível de um dos lados. Você olha os dois, eles parecem iguais, e não são.

Duas defesas:

1. O prompt já manda a função comparar removendo espaços das duas pontas. Isso resolve o caso do espaço invisível.
2. Se acontecer mesmo com essa defesa, aí o valor é genuinamente diferente. Gere um segredo novo e cole nos dois lugares na mesma sessão: primeiro na variável, depois no disparo.

Aconteceu comigo, e eu não sei desde quando estava quebrado. Os avisos simplesmente não chegavam, e como nada dava erro na tela, ninguém percebeu.

Anote no seu arquivo do capítulo 1: se os avisos pararem, esse é o suspeito número 1.

6. Armadilhas

Testar no aplicativo de teste rápido. Não funciona. Nem um pouco.

Deixar a função sem segredo próprio. Ela é chamada pelo painel, não por um usuário logado, então normalmente não exige login. Se ela também não conferir um segredo, qualquer pessoa que descubra o endereço dispara aviso pros seus usuários.

Deixar um aparelho ruim derrubar o envio. Se uma pessoa desinstalou o app, o endereço dela fica inválido. Se a função parar no primeiro erro, ninguém mais recebe.

Mandar aviso da própria ação. A pessoa manda mensagem e recebe notificação da mensagem que ela mesma mandou. Parece bobo, e acontece toda vez.

Não testar troca de celular. A pessoa troca de aparelho, o endereço antigo morre. O app precisa registrar o novo ao abrir.

7. Terminou quando

• Você gerou a versão instalável e está testando num aparelho de verdade.
• Com dois aparelhos (ou duas contas), um mandou mensagem e o outro recebeu o aviso com o app fechado.
• Tocou no aviso e o app abriu na conversa certa.
• Quem mandou a mensagem não recebeu aviso da própria mensagem.
• Testou todos os tipos de aviso, não só o de mensagem.
• Desligou a notificação nas configurações do app e o aviso parou de chegar.
• Abriu os registros da função e viu as chamadas com sucesso, não erro de autorização.
• Anotou no arquivo do capítulo 1 o que checar primeiro se parar.

Resumo do capítulo

⚠️ Leia o aviso da seção 2 antes de decidir quando fazer este capítulo. Ele está numerado como 15 porque é a posição dele no curso. Não é a posição certa.

O que você vai fazer neste passo

Definir quem o seu app é, não como ele se parece.

Não é escolher cor nem fonte. É decidir que sensação ele provoca, como ele fala, o que ele nunca faria, e por que alguém escolheria ele em vez de outro igual.

Por que isso importa

Existem cinquenta apps que fazem o que o seu faz. O que separa o seu não é a funcionalidade: é ser reconhecível.

E tem um efeito prático, que é o que mais me surpreendeu: a personalidade resolve discussão. Toda vez que eu não sabia se um texto ou uma tela estava certa, eu voltava nos três princípios que saíram deste capítulo e a resposta aparecia em dez segundos. Antes disso, eu ficava vinte minutos girando.

2. O aviso: este capítulo está no lugar errado

Faça este capítulo antes do capítulo 2 (o desenho das telas).

O curso coloca a marca no fim. É a ordem intuitiva: primeiro você faz o app, depois pensa na identidade. E é errado, por um motivo simples: o desenho toma decisões de marca sem saber que está tomando.

Eu fiz na ordem do curso e paguei. Contei no capítulo 2 e a prova está aqui:

Quando rodei este prompt, a primeira coisa que a resposta fez foi listar os clichês da minha categoria pra eu evitar. Um deles:

Gamificação derivada, troféu dourado, confete, streak com chama, mascote arredondado fofo.

O meu mockup, desenhado um mês antes, tinha exatamente isso: a sequência de dias treinados marcada com uma chama.

Eu tinha desenhado o clichê da categoria sem saber que era clichê. E aí tive que voltar, refazer o ícone, refazer a tela de comemoração, tirar o confete.

Se eu tivesse feito este capítulo primeiro, teria desenhado certo de primeira.

3. O prompt (cole isso)

Você é um estrategista de marca e Product Designer especializado em
aplicativos mobile.

Quero encontrar uma personalidade forte, reconhecível e difícil de confundir
com outros aplicativos da mesma categoria.

Não quero apenas uma paleta de cores ou um estilo visual bonito. Quero
definir QUEM esse produto é, que sensação ele provoca, e como essa
personalidade aparece tanto dentro do aplicativo quanto na comunicação.

## Meu aplicativo
O que o app faz: [DESCREVA]
Principal problema que resolve: [DESCREVA]
Público que quero atingir: [DESCREVA]
Faixa etária aproximada: [DESCREVA]
Contexto em que essas pessoas usariam o app: [DESCREVA]
Concorrentes ou apps semelhantes: [OPCIONAL]
Alguma referência que eu gosto: [OPCIONAL]

## Sua tarefa

Primeiro, identifique os CLICHÊS dessa categoria e liste-os, pra eu saber o
que evitar. Diga qual pressuposto todos eles compartilham.

Depois, proponha 4 DIREÇÕES DE PERSONALIDADE realmente diferentes entre si.
Não quero quatro variações da mesma estética. Quero quatro possibilidades
que transformariam o mesmo produto em marcas completamente diferentes.

Para cada direção, defina:
1. CONCEITO CENTRAL: uma frase forte. Não use adjetivos genéricos como
   "moderno, jovem e amigável". Explique a ideia por trás.
2. SE O APP FOSSE UMA PESSOA: comportamento, atitude, jeito de falar, e a
   sensação que causaria.
3. RELAÇÃO COM O PÚBLICO: por que essa personalidade faz sentido pra esse
   público. Que desejo ou emoção ela explora.
4. UNIVERSO VISUAL: fotografia ou ilustração, cores, tipografia, formas,
   ícones. Cada decisão precisa reforçar a personalidade, não só ser bonita.
5. ELEMENTO DE IDENTIDADE: mascote, pessoas reais, ilustração, fotografia,
   um elemento gráfico recorrente, ou nenhum. Se recomendar mascote,
   explique quem ele é e por que criaria vínculo. Não presuma que mascote é
   sempre a melhor solução.
6. PERSONALIDADE DENTRO DO PRODUTO: como isso muda o onboarding, as
   mensagens, as conquistas, as notificações, as telas vazias.
7. TOM DE VOZ: como a marca fala, com 3 exemplos curtos de frases reais.
8. CONTEÚDO E MARKETING: 3 ideias de conteúdo que só fariam sentido dentro
   desse universo.
9. O QUE NÃO FAZER: decisões e clichês que enfraqueceriam essa direção.
10. NOTAS de 0 a 10 para: distinção, memorabilidade, afinidade com o
    público, e potencial de expansão.

## Depois das 4 propostas

Compare as quatro. Escolha a de maior potencial e explique por quê.
Identifique também qual é a MAIS SEGURA, a MAIS DISTINTA e a MAIS OUSADA.

Por último, transforme a mais promissora num DNA DA MARCA:
- Somos: 5 características
- Não somos: 5 características
- Queremos fazer o usuário sentir: 3 emoções
- Nossa personalidade em uma frase
- Princípio visual: 1 frase
- Princípio de comunicação: 1 frase

## Regras

Não confunda identidade visual com personalidade de marca.
Não comece escolhendo cores. Comece entendendo quem o produto deve ser.
Evite respostas genéricas que serviriam pra qualquer aplicativo.
Não copie marcas famosas: use como referência de nível, não de estética.
Não tente agradar todo mundo. Uma personalidade forte conversa melhor com
um grupo específico.

Se minhas informações forem insuficientes, faça perguntas antes de criar as
quatro direções.

Como preencher

Preencha todos os [DESCREVA]. Este prompt não funciona com eles em branco: ele não tem código pra ler, só o que você contar.

Escreva como você explicaria pra um amigo, não como texto de propaganda.

4. O que esperar

Uma resposta longa: quatro direções completas com dez seções cada, mais a comparação e o DNA. É bastante texto.

Leia tudo antes de escolher. A tentação é pegar a primeira que soa bem.

E um aviso de custo: essa saída longa gasta mais que uma tarefa normal. Se você estiver perto de um limite de uso, faça num momento em que possa esperar.

5. O que aconteceu comigo

O mapa de clichês valeu tanto quanto as direções

Antes das quatro propostas, veio a lista do que não ser na minha categoria:

• Beast mode, preto, neon, itálico condensado, “sem dor sem ganho”
• Wellness pastel, bege e sage, luz natural, “sua jornada”
• Gamificação derivada, troféu dourado, confete, streak com chama, mascote fofo
• Dashboard de dados, anéis de progresso, números gigantes, neon
• Antes e depois, corpo transformado como prova
• Motivacional de banco de imagem, frase de efeito sobre nascer do sol

E aí a frase que amarra tudo:

“Todos partem do mesmo pressuposto: o inimigo é a sua preguiça e o herói é você sozinho.”

Essa frase única fez mais pela minha marca do que qualquer escolha de cor. Ela me deu o que atacar.

A direção escolhida saiu da mecânica do produto, não da estética

A direção vencedora chamava-se “O Combinado”:

“A categoria inteira vende auto-superação. Aqui o motor não é você: é não deixar alguém na mão. É sobre a palavra dada: quem marca, aparece.”

Se fosse uma pessoa: o amigo que não dá bolo. Não é o mais forte da academia nem o mais animado: é aquele que, se disse que vai, vai.

E o detalhe que me convenceu, sobre o símbolo da marca:

“O check duplo, que já é literalmente a regra do seu banco de dados. O símbolo da marca é a mecânica do produto: isso é raro e vale muito.”

O app já tinha, no banco, uma regra de que um treino só conta quando as duas pessoas confirmam. A marca não inventou um símbolo: ela encontrou o que já estava lá.

Procure isso no seu app. A coisa mais distintiva da sua marca provavelmente já existe como regra no seu código, e ninguém percebeu ainda.

O que os três princípios resolveram no dia a dia

Do DNA final, três frases viraram ferramenta de trabalho:

Princípio visual. “Mostramos o encontro, nunca o corpo, e o laranja é a cor do confirmado, não papel de parede.”

Princípio de comunicação. “Falamos de palavra cumprida, não de motivação. Se a frase caberia em qualquer app de academia, não é nossa.”

Não somos. Motivacionais, julgadores, obcecados por corpo, infantis, nem obcecados por performance.

O segundo princípio é o que eu mais uso. É um teste de uma linha que resolve qualquer dúvida de texto, e reprova a maioria das primeiras tentativas.

O que eu decidi não mudar

O resultado apontou uma tensão real: meu slogan é corporativo e em inglês, enquanto a marca é calorosa e brasileira. Fazia sentido.

Mantive o slogan mesmo assim, e anotei a decisão com a data.

Não é obrigatório aceitar tudo. O que é obrigatório é decidir e escrever, senão a mesma discussão volta todo mês.

6. Armadilhas

Fazer depois do desenho. Foi meu erro, e é o motivo do aviso no topo.

Escolher a direção mais segura. Ela costuma ser a mais parecida com todo mundo. Se o objetivo é ser reconhecível, “mais segura” trabalha contra você.

Guardar o resultado num arquivo que ninguém abre. O valor está nos três princípios sendo usados. Coloque-os no arquivo do capítulo 1.

Tentar agradar todo mundo. Personalidade que não afasta ninguém não atrai ninguém.

Achar que isso é papo de marketing. Sai daqui: o texto das notificações, o que as telas vazias dizem, o ícone da sequência, o que a tela de comemoração mostra. É produto.

7. Terminou quando

• Você tem a lista de clichês da sua categoria escrita.
• Você consegue dizer qual pressuposto todos eles compartilham.
• Escolheu uma direção e escreveu por quê.
• Tem os cinco “não somos” escritos.
• Tem o princípio visual e o de comunicação, uma frase cada.
• Os três princípios estão no arquivo do capítulo 1.
• Você olhou as telas já prontas e listou o que contradiz a direção nova.
• As decisões que você recusou estão anotadas, com a data e o motivo.

Resumo do capítulo

⚠️ Este é o primeiro prompt do livro cuja resposta certa pode ser “não use”. No meu app a marca já tinha dito que não, e eu rodei assim mesmo, pra ver. A folha ficou boa e continua não sendo a minha marca. A seção 1 explica como decidir antes de gastar tempo aqui.

O que você vai fazer neste passo

Gerar uma folha de referência de um personagem: a mesma figura desenhada de vários ângulos e com várias expressões, numa imagem só.

Isso não é arte final. É a peça que você guarda pra, daqui a três meses, conseguir gerar uma imagem nova daquele personagem sem ele mudar de cara.

Por que isso importa (quando importa)

Gerador de imagem não tem memória. Peça “meu mascote acenando” hoje e “meu mascote correndo” amanhã, e vão sair dois bichos diferentes com o mesmo nome.

A folha de referência resolve isso: você anexa ela junto do pedido, e o gerador tem de onde copiar. É o que transforma um desenho bonito num personagem reutilizável.

Sem ela, você não tem um personagem. Tem uma coleção de desenhos parecidos.

1. Antes de tudo: você precisa de um personagem?

Pare aqui. Esta é a pergunta que decide se o capítulo inteiro serve pra você.

Quem responde isso não é você agora, é o capítulo 15. O prompt da marca tem um item chamado ELEMENTO DE IDENTIDADE, que pergunta exatamente isto: mascote, pessoas reais, ilustração, fotografia, um elemento gráfico recorrente, ou nenhum.

Faça o capítulo 15 primeiro. Se a resposta dele for mascote ou personagem, volte pra cá. Se não for, pule este capítulo inteiro e não perca nada.

Três motivos pra desconfiar do mascote

Costuma ser clichê da categoria. No meu caso, “mascote arredondado fofo” apareceu na lista de clichês a evitar, junto de troféu dourado e confete. Se todo concorrente tem um bichinho simpático, o seu não te diferencia: te mistura.

Mascote é trabalho pra sempre. Ele precisa aparecer no onboarding, nas telas vazias, nas conquistas, nos posts. Cada tela nova é uma pose nova. Você não está escolhendo um desenho, está assinando um contrato de manutenção.

Fofo não é personalidade. Um personagem só cria vínculo se ele for alguém: tem jeito, tem opinião, reage. Se você não consegue dizer quem ele é em uma frase, ele é enfeite, e enfeite não sobrevive ao segundo mês.

O que pode entrar no lugar

Personagem é uma das formas de ter um elemento visual que se repete. Não é a única, e costuma ser a mais cara.

• Pessoas reais, sempre na mesma situação
• Um objeto gráfico fixo que reaparece em todo lugar
• Um gesto ou símbolo tirado do que o seu app faz
• Nada disso, e a marca vive de tipografia, cor e enquadramento

O objeto costuma ser o melhor negócio de todos: ele não tem ângulo errado, não tem expressão fora de personagem, e não precisa de folha de referência nenhuma pra ficar igual.

2. O prompt (cole isso)

Roda num gerador de imagens, igual ao do capítulo 2. Não é na IA de código.

Crie uma folha de referência visual do personagem abaixo:

[DESCREVA O PERSONAGEM OU ANEXE UMA IMAGEM DE REFERÊNCIA]

Expressões que quero explorar:
[INFORME AS EXPRESSÕES OU DEIXE EM BRANCO]

Use fundo branco e organize o personagem em uma composição horizontal,
limpa e bem espaçada.

Na primeira linha, mostre o mesmo personagem em quatro ângulos:
- frente
- 3/4
- lateral
- costas

Na segunda linha, mostre o personagem em diferentes expressões e poses. Use
as expressões que informei acima. Caso eu não especifique nenhuma, escolha
quatro que façam sentido para a personalidade e o contexto do personagem.

Mantenha o personagem consistente em todas as versões. Rosto, corpo,
proporções, cabelo, roupas, acessórios, cores e características visuais
devem permanecer iguais. O que muda são apenas o ângulo, a pose e a
expressão.

Se eu enviar uma imagem como referência, use-a como base principal e não
redesenhe o personagem. Preserve sua identidade e seu estilo visual.

Respeite também o tipo de estética original. Se for uma pessoa realista,
mantenha realista. Se for um mascote 3D, mantenha 3D. Se for vetor,
ilustração ou outro estilo, mantenha essa mesma linguagem visual.

Para pessoas realistas, as diferentes posições devem parecer fotos da mesma
pessoa feitas na mesma sessão, com aparência natural e iluminação
consistente.

Mostre o personagem inteiro sempre que possível, sem cortar cabeça, cabelo,
mãos, pés ou acessórios importantes.

Adicione uma pequena paleta com as principais cores do personagem em uma
das laterais.

Use apenas pequenos rótulos para identificar os ângulos e as expressões.
Não coloque título na composição e não escreva "Character Sheet" na imagem.

Não adicione cenário, mockup, textos explicativos ou elementos decorativos.
O foco deve estar exclusivamente no personagem e na consistência entre
todas as suas variações.

O resultado final deve parecer uma folha profissional de referência visual
pronta para ser usada como base na criação de novas imagens do mesmo
personagem.

Como preencher

Se você já tem uma imagem, anexe. É a diferença entre pedir pra IA lembrar de um personagem e pedir pra ela copiar um. A segunda funciona muito melhor.

3. O que esperar

Uma imagem, fundo branco, duas fileiras: quatro ângulos em cima, quatro expressões embaixo. Uma paleta de cores na lateral. Rótulos pequenos.

O que conferir, e é aqui que quase sempre falha:

Olhe as oito figuras e procure o que mudou sem você pedir. Roupa que trocou de cor entre a frente e as costas. Acessório que sumiu no perfil. Cabelo mais comprido numa pose. Altura diferente entre as duas fileiras.

Achou? Gere de novo. Uma folha com inconsistência é pior que nenhuma folha, porque você vai usar ela de base e propagar o erro pra todas as imagens seguintes.

Guarde o arquivo junto do resto da marca. Ele vale tanto quanto o mapa de cores, e pelo mesmo motivo: é o que mantém tudo igual quando o tempo passa.

4. O que aconteceu comigo

Quando fiz o capítulo da marca, a resposta ao item ELEMENTO DE IDENTIDADE foi direta:

“Sem mascote. Pessoas reais, sempre em par, nunca um modelo sozinho. E um elemento gráfico fixo: o check duplo, que já é literalmente a regra do seu banco de dados.”

O símbolo da marca não veio de um desenho. Veio de uma regra que o app já tinha: um treino só conta quando as duas pessoas confirmam. Dois “certos” se encaixando.

Isso é mais barato e mais forte que qualquer mascote. Não precisa de folha de referência, não tem ângulo errado, e significa alguma coisa.

As outras três propostas também recusaram

O prompt do capítulo 15 gera quatro direções de marca. Nenhuma das quatro propôs um personagem. Uma delas dizia, com todas as letras:

“Quase sem mascote e quase sem foto. O elemento é o cartão de combinado, um objeto gráfico fixo com hora, lugar, os dois nomes e o status. Esse mesmo cartão é o card no chat, o print compartilhado, o anúncio e o post. Um objeto só, repetido em todo lugar.”

Repare no raciocínio: ela também queria um elemento que se repete, que é o ponto do personagem. Só que escolheu um objeto em vez de uma criatura.

Objeto não tem expressão pra manter coerente, não tem ângulo que sai errado, e não precisa de manutenção. Faz o mesmo trabalho por uma fração do custo.

Rodei mesmo assim, só pra ver

Escrevi uma versão adaptada ao meu app e gerei. Este é o resultado:

O que ela me ensinou, e vale pra você:

Confira a paleta contra os seus valores reais. A folha lista #FF6B00 como laranja da marca. O laranja do meu app é #FF6A13. O gerador arredondou pra um valor mais “redondo”. São dois tons quase iguais de olho, e é exatamente por isso que passa batido: se essa folha virar a referência de tudo que vem depois, todo material futuro puxa um laranja que não é o do app.

O prompt decide se a saída cabe na sua marca. Eu escrevi “transmitir energia, motivação, espírito esportivo”. Olhe o que voltou: punho cerrado em “motivado” e bíceps duplo em “comemorando uma conquista”. São os dois gestos mais batidos da categoria, e estavam na lista de clichês que o meu próprio trabalho de marca mandou evitar.

A IA não errou. Ela entregou com precisão o que eu pedi. Eu é que pedi a coisa que a minha marca já tinha recusado, porque escrevi o prompt olhando pro app genérico de academia em vez de olhar pro que eu tinha decidido.

Foi o mesmo erro do capítulo 2, na mesma ordem: o desenho andando na frente da marca. Só que dessa vez eu tinha a marca escrita e ainda assim escorreguei.

Por isso a folha existe e não é oficial. Ela prova que a técnica funciona, e prova junto que técnica boa não salva pedido errado.

5. Armadilhas

Rodar este capítulo antes do capítulo 15. Aí você decide ter um mascote porque ficou bonitinho, não porque a marca pediu. É a mesma inversão de ordem que me custou retrabalho com o desenho das telas.

Escolher personagem por ser fofo. Fofo é como ele parece. Personagem é quem ele é. Se você não consegue dizer o que ele faria numa tela de erro, não é personagem.

Aceitar a folha sem conferir figura por figura. É o erro caro: a inconsistência entra na base e se espalha por tudo que você gerar depois.

Não guardar o arquivo. Sem a folha, daqui a três meses você tem um personagem diferente com o mesmo nome.

Esquecer que ele custa pra sempre. Cada tela nova vira uma pose nova. Se você não tem fôlego pra isso, o objeto gráfico faz o mesmo serviço e não cobra manutenção.

6. Terminou quando

• O capítulo 15 disse, com essas palavras, que a sua marca usa personagem.
• Você consegue dizer quem ele é em uma frase, sem falar de aparência.
• A folha tem os quatro ângulos e as quatro expressões.
• Você comparou as oito figuras procurando o que mudou sem pedir, e não achou nada.
• A paleta de cores do personagem está na imagem.
• Nenhuma figura está cortada em cabeça, mãos, pés ou acessório.
• O arquivo está guardado junto do resto do material de marca.
• Você testou: gerou uma imagem nova anexando a folha, e saiu o mesmo personagem.

O último item é o único que prova que a folha funciona. Faça ele.

Resumo do capítulo

Não existe prompt do curso pra este capítulo. O modelo de arquivo do capítulo 1 até menciona assinatura, e o de onboarding fala em entregar pro paywall, mas nenhum prompt constrói a cobrança.

O que você vai fazer neste passo

Fazer o app cobrar de verdade: alguém aperta um botão, paga, e ganha acesso a alguma coisa que quem não paga não tem.

Por que isso importa

Cobrar num app não é como cobrar num site. Você não pode simplesmente processar um cartão. As duas lojas (Google e Apple) obrigam que compras de conteúdo digital passem pelo sistema de pagamento delas, e ficam com uma parte.

Isso muda tudo: você não escolhe o meio de pagamento, não vê o cartão, e não controla o momento da cobrança. O que você faz é perguntar às lojas se aquela pessoa está pagando, e liberar ou não.

Quando fazer

Depois da segurança (capítulo 11). Cobrança em cima de app que qualquer um consegue burlar é dinheiro jogado fora, a primeira coisa que alguém faz é se marcar como assinante de graça.

1. A decisão mais importante: o que você vende

Antes de qualquer código. Três modelos, e a escolha muda o resto:

Assinatura. Paga por mês, tem acesso enquanto pagar. Melhor pra app que a pessoa usa toda semana.

Compra única. Paga uma vez, tem pra sempre. Melhor pra ferramenta.

Consumível. Paga por uso, um pacote de créditos. Melhor quando cada uso te custa dinheiro (chamada de IA, por exemplo).

E a pergunta mais difícil: o que exatamente fica atrás do pagamento?

Duas regras que aprendi:

Não cobre pelo que faz o app funcionar. Se a coisa principal é paga, quem não paga não tem o que fazer, e nunca vira assinante.

Cobre por mais, não por acesso. Mais alcance, mais destaque, mais limite. A pessoa já sentiu o valor e quer mais dele.

No meu app: quem não paga encontra parceiros até uma distância limitada. Quem paga aumenta o raio, filtra melhor, e aparece no topo da lista dos outros. Ninguém fica sem usar.

2. Não construa a cobrança do zero

Existe um problema chato: cada loja tem um jeito diferente de dizer se alguém está pagando, e você teria que lidar com renovação, cancelamento, reembolso, período de teste, mudança de plano, nas duas.

Existe um tipo de serviço que faz isso por você, e fala com as duas lojas em nome do seu app. Ele avisa o seu servidor quando alguém assina ou cancela.

Use um. Construir isso à mão não vale.

3. A regra que não pode ser quebrada

Quem decide se a pessoa é assinante é o servidor. Nunca o app.

Se o app guardar “essa pessoa é premium” e confiar nisso, qualquer um consegue mudar, e a essa altura do livro você já sabe que dá pra falar com o banco direto, sem passar pelas telas.

O fluxo certo:

1. A pessoa paga na loja.
2. A loja avisa o serviço de cobrança.
3. O serviço de cobrança avisa o seu servidor.
4. O seu servidor marca a pessoa como assinante no banco.
5. A coluna que diz isso é impossível de escrever pelo app.

O passo 5 é o que fecha. Sem ele, os outros quatro não valem nada.

4. O prompt (cole isso)

Crie a fase de cobrança do [NOME DO APP]. Use o CLAUDE.md como contrato.

ANTES DE QUALQUER COISA, leia e verifica:
- Existe alguma coluna no banco marcando quem é assinante? Ela é gravável
  pelo app? Se for, isso é um furo e precisa ser fechado nesta fase.
- Mapeie TUDO que esta fase exige fora do código: conta de desenvolvedor nas
  lojas, conta no serviço de cobrança, produto cadastrado, versão instalável
  do app. Liste cada item como FEITO ou PENDENTE. Não presuma nada como
  feito.
- Considere que eu NUNCA usei esses painéis. Toda instrução tem que ser
  "clique em tal botão, no menu tal, digite exatamente isso".

O QUE VOU VENDER:
- Modelo: [assinatura mensal / compra única / créditos]
- Preço: [VALOR]
- O que o pagante ganha: [LISTE]
- O que quem não paga continua podendo fazer: [LISTE]

PRINCÍPIOS (não-negociáveis):
- Quem decide se a pessoa é assinante é o SERVIDOR. O app só pergunta.
- A coluna que marca assinante tem que ser IMPOSSÍVEL de escrever pelo app.
  Se hoje for gravável, feche nesta fase.
- O limite do plano grátis é imposto no servidor, não na tela. A tela só
  reflete o que o servidor decidiu.
- Restaurar compra tem que funcionar: a pessoa troca de celular e recupera o
  que pagou.
- Quem não paga nunca fica travado sem poder usar o app.

ESCOPO:
- Aqui: a tela de venda, a compra, o aviso do serviço pro meu servidor, a
  liberação do benefício, e restaurar compra.
- Fora: campanhas, cupom de desconto e promoções.

ANTES DE CRIAR OU MUDAR ARQUIVOS, me entrega:
1. RESUMO EM PRODUTO. O que acontece quando: compra com sucesso, cancela,
   a assinatura vence, troca de celular, e pede reembolso.
2. PONTOS DE DECISÃO em português comum. Inclua: onde a tela de venda
   aparece no app, e o que a pessoa vê quando o benefício acaba.
3. PLANO TÉCNICO, com o CÓDIGO COMPLETO da função que recebe o aviso do
   serviço de cobrança, pronto pra eu colar no painel.
4. MANUAL DE CONFIGURAÇÃO passo a passo, incluindo como testar a compra SEM
   gastar dinheiro de verdade e sem a loja aprovada.

Espera minha aprovação antes de criar ou mudar arquivos.

5. Teste sem gastar e sem esperar a loja

Você não precisa da loja aprovada pra testar. Os serviços de cobrança têm um modo de teste que simula a compra inteira, de graça.

Use isso desde o começo. Foi como eu testei o meu de ponta a ponta: compra simulada, o servidor recebendo o aviso, o benefício ativando, o contador funcionando.

⚠️ Mas saiba o que o modo de teste não prova. Ele testa a sua lógica, não a das lojas. Continua faltando: o produto cadastrado no painel da loja de verdade, o preço em reais aprovado, e a cobrança real acontecendo.

Eu testei tudo no modo de teste e ainda não testei com dinheiro real, porque isso depende de uma conta de desenvolvedor paga, que é o assunto do próximo capítulo.

Está funcionando? Sim. Está provado? Não completamente. Saiba a diferença.

6. A armadilha que você vai criar sem perceber

Uma coisa que descobri planejando uma parceria, e que vale te avisar antes:

Em algum momento você vai querer dar a assinatura de graça pra alguém, um parceiro, um influenciador, um amigo que ajudou. É natural.

O jeito óbvio é ir no banco e marcar a pessoa como assinante na mão. Funciona.

O problema: essa pessoa fica idêntica a um assinante pagante. Se um dia você olhar “quantos assinantes ativos eu tenho”, o número vem inflado, e você não tem como separar.

A defesa é barata se feita agora: guarde também como a pessoa virou assinante, comprou, ganhou de cortesia, está em teste. Uma coluna a mais.

Depois de cem cortesias dadas, não tem mais como reconstruir.

7. Onde NÃO colocar a tela de venda

O modelo de arquivo do capítulo 1 sugere pôr o paywall no caminho de entrada: a pessoa responde o onboarding, vê a tela de venda, e depois cria a conta.

Eu não fiz isso, e não recomendo pra app social.

O motivo: num app onde o valor depende de outras pessoas estarem lá, pedir dinheiro antes da pessoa ver alguém é pedir fé. Ela não tem como saber se vale.

No meu app a tela de venda mora nas configurações, e a pessoa chega nela quando esbarra num limite, quando ela já quis fazer algo e não pôde. Aí o valor está claro.

Para app individual (uma ferramenta que funciona sozinha, sem depender de outros usuários), o paywall na entrada faz mais sentido: a pessoa já consegue avaliar o valor no onboarding.

Decida pelo tipo do seu app, não pelo que o modelo diz.

8. Armadilhas

Deixar a coluna de assinante gravável pelo app. É o furo mais óbvio e o mais comum. Teste: tente se marcar como premium falando direto com o banco.

Não testar restaurar compra. A pessoa paga, troca de celular, perde o acesso, pede reembolso e xinga você na avaliação da loja.

Cobrar pela coisa principal. Quem não paga não tem o que fazer, e vai embora antes de considerar pagar.

Achar que o modo de teste prova tudo. Ele prova a sua lógica. Não prova o preço, o produto cadastrado, nem a cobrança real.

Não marcar quem ganhou de graça. Sua métrica de assinantes mente pra você.

9. Terminou quando

• Você tentou se marcar como assinante falando direto com o banco e falhou.
• Fez uma compra no modo de teste e o benefício ativou.
• O servidor recebeu o aviso da compra, você viu nos registros.
• Cancelou no modo de teste e o benefício foi removido.
• Testou restaurar compra.
• Navegou pelo app com uma conta que não paga: nada ficou travado.
• Bateu num limite do plano grátis e viu uma mensagem clara.
• Existe uma forma de distinguir quem pagou de quem ganhou.

Resumo do capítulo

Não existe prompt do curso pra este capítulo. E é o único do livro que não é sobre código: é sobre burocracia, contas pagas e espera.

O que você vai fazer neste passo

Tirar o app do seu computador e colocar onde as pessoas conseguem baixar.

Por que isso importa

É o capítulo onde a maioria dos projetos morre. Não por dificuldade técnica: por não saber o que era preciso, descobrir tarde, e desanimar.

Este capítulo é uma lista de tudo que você vai precisar, pra você saber antes o que vem pela frente.

1. O que custa dinheiro

Não tem como fugir:

Recomendação: comece pelo Android. Vinte e cinco dólares uma vez, aprovação mais simples, e você aprende o processo inteiro pela metade do custo. O iPhone depois, quando o app já estiver validado.

⚠️ Uma coisa que ninguém avisa: a conta paga da Apple não é só pra publicar. Sem ela você não consegue nem gerar uma versão instalável pra testar no seu próprio iPhone. Coisas que dependem dela: notificações, login com Apple, widgets, e qualquer parte nativa do sistema.

No Android, gerar versão de teste é gratuito. É mais um motivo pra começar por lá.

2. O que as lojas exigem, e quase ninguém sabe

Além do app funcionando, as duas pedem:

Uma página pública de Política de Privacidade. Um endereço na internet, que qualquer um consiga abrir, dizendo que dados você coleta e o que faz com eles. Sem isso a ficha não é aceita.

Uma página pública de Termos de Uso. Mesma coisa.

Capturas de tela em tamanhos específicos.

Ícone do app em alta resolução.

Descrição curta e longa.

Uma classificação etária, respondendo um questionário sobre o conteúdo.

Um formulário de segurança de dados, declarando o que o app coleta. Precisa bater com a realidade: se declarar errado, a loja pode remover o app depois.

3. Você vai precisar de um site (mesmo sem querer um site)

Aquelas duas páginas públicas são o motivo pelo qual eu tenho um site.

Não é site de marketing. São duas páginas de texto, HTML puro, hospedadas de graça. Existem porque as lojas exigem um endereço público, e um documento dentro do app não serve, tem que ser um link que abre no navegador.

Faça isso cedo, não no dia de publicar. Comprar domínio e apontar o endereço leva algumas horas e às vezes um dia pra propagar.

⚠️ Duas armadilhas que me pegaram:

A primeira: se o seu site tiver alguma proteção de acesso ligada, ninguém de fora consegue abrir, inclusive quem for revisar o seu app na loja. Aconteceu comigo explorando o painel sem querer. Abra o endereço numa janela anônima e confirme que carrega sem pedir login.

A segunda: as páginas do site e as telas de termos dentro do app são dois textos separados. Mudou um, mude o outro. É fácil esquecer e ficar com versões diferentes do mesmo documento legal.

4. Lançar numa cidade só

Uma decisão que eu tomei e recomendo pensar: não lance pro país inteiro de uma vez.

No meu app, isso é essencial, ele conecta pessoas que treinam perto uma da outra. Cem usuários espalhados pelo Brasil significa zero parceiros pra cada um, e o app parece quebrado sem estar. Os mesmos cem usuários numa cidade só é um app que funciona.

Como eu fiz: uma tela no começo do cadastro que pede a localização e calcula a distância até um ponto central. Fora do raio, a pessoa vê “ainda não chegamos na sua região” e o email dela fica marcado pra quando expandir.

Dois detalhes que valem copiar:

O raio e o ponto central são duas linhas de configuração no topo do arquivo. Abrir pra outra cidade é mudar um número, não é refazer nada.

Eu não criei lista de espera com formulário próprio. O email já estava salvo do cadastro; só marquei quem ficou de fora. Formulário separado seria trabalho duplicado.

Isso vale pro seu app? Se ele depende de outras pessoas por perto, sim. Se funciona sozinho, não faz sentido.

5. O prompt (cole isso)

Este é o único capítulo em que a IA não constrói: ela organiza e te guia.

Preciso publicar o [NOME DO APP] nas lojas. Use o CLAUDE.md como contrato.

Analise o projeto e me entregue um plano de lançamento, considerando que eu
NUNCA publiquei um app e não conheço nenhum desses painéis.

1. INVENTÁRIO DO QUE FALTA
   Analise o app e liste tudo que ainda impede a publicação:
   - ícone e telas de abertura nos tamanhos certos
   - permissões que o app pede e a justificativa de cada uma (as lojas
     perguntam)
   - bibliotecas que exigem declaração especial
   - qualquer coisa no código que as lojas costumam recusar
   Marque cada item como FEITO ou PENDENTE.

2. O QUE O APP COLETA
   Analise o banco e o código e liste TODOS os dados pessoais que o app
   coleta, com a finalidade de cada um. Preciso disso pra:
   a. preencher o formulário de segurança de dados da loja
   b. escrever a política de privacidade
   Não invente nem omita: isso tem consequência legal.

3. AS PÁGINAS PÚBLICAS
   Escreva a política de privacidade e os termos de uso, baseados no que o
   app REALMENTE coleta (item 2), não em modelo genérico. Em português
   comum. Me entregue como páginas prontas pra publicar.

4. PASSO A PASSO DA PUBLICAÇÃO
   Para [Google Play / App Store], na ordem: criar a conta, o que preencher
   em cada campo, como gerar o arquivo do app, como enviar, quanto tempo
   demora a análise, e os motivos mais comuns de recusa.

5. TESTE ANTES DE ENVIAR
   O que eu devo testar num aparelho de verdade antes de mandar pra análise.

Espera minha aprovação antes de criar arquivos.

6. A ordem que eu recomendo

1. Páginas públicas no ar (mais fácil, e trava tudo se faltar)
2. Conta do Google Play (US$ 25: a verificação de identidade demora)
3. Versão instalável e teste de verdade no aparelho
4. Ficha da loja (textos, capturas, classificação)
5. Formulário de segurança de dados
6. Enviar e esperar
7. App Store depois, quando o Android estiver de pé

7. Armadilhas

Deixar as páginas públicas pro fim. É o item mais fácil e trava tudo.

Declarar errado o que o app coleta. Se você declarar menos do que coleta e a loja perceber, o app é removido. É por isso que o prompt manda a IA derivar isso do código, não de modelo pronto.

Não testar num aparelho de verdade antes de enviar. Rodar no simulador não é prova. Instale a versão final no seu celular e use por um dia.

Deixar a proteção de acesso ligada no site. O revisor não consegue abrir a sua política de privacidade, e a análise é recusada.

Achar que publicar é o fim. É o começo. Depois vem atualização, avaliação, suporte, e aí você vai agradecer o arquivo do capítulo 1 e a revisão do capítulo 12.

8. Terminou quando

• Política de privacidade e termos estão no ar, e você abriu os dois numa janela anônima.
• O texto das páginas bate com o das telas dentro do app.
• A conta de desenvolvedor está criada e a identidade verificada.
• Você instalou a versão final no seu celular e usou por um dia inteiro.
• O formulário de segurança de dados foi preenchido a partir do que o app realmente coleta.
• Ícone e capturas estão nos tamanhos exigidos.
• Você testou o app com uma conta nova, do zero, como um usuário de verdade.
• Se lançar por região: testou tanto dentro quanto fora do raio.

Resumo do capítulo