| Auditoria de rastreabilidade tardia | RF36 (F19) tinha um critério de aceite marcado como concluído — reativação de lead — sem que a funcionalidade existisse (nem endpoint, nem UI). Só foi descoberto ao auditar a rastreabilidade linha a linha antes de marcar as features como Concluída (MR.01) | Auditar a rastreabilidade (AC documentado × comportamento implementado) antes de fechar cada feature, não só antes de marcar a iteração inteira como concluída |
| Divergência entre texto e implementação mais segura | RF53/RN22 (F21) descreviam remoção de interação como exclusão permanente (hard-delete); a implementação real sempre foi soft-delete — mais seguro, mas divergente do texto (MR.01) | Quando a implementação diverge do requisito documentado de forma mais segura, o padrão passa a ser corrigir o texto para refletir a realidade, em vez de reescrever o código para bater com um requisito desatualizado |
| RNF sem lastro em evidência real | RNF20 ("disponibilidade 24/7 institucional, uptime ≥ 99%") nunca foi medido nem monitorado de fato — era um RNF que a equipe não tinha meios de verificar | RNFs que descrevem uma métrica não instrumentada/monitorada devem ser convertidos em Regra de Negócio (escopo/comportamento) em vez de permanecerem como RNF não verificável. Ver RN27 |
| Gap de LGPD não coberto por um RNF existente | F15 (institucional) não tinha nenhum RNF de LGPD, embora RNF11 já cobrisse LGPD para outras features de captação de dados — F15 não captura dado, mas precisa declarar isso explicitamente | Ao revisar RNFs "globais" (como LGPD), checar explicitamente cada feature que lida com dado de visitante, mesmo as que aparentemente não capturam nada — resultou na criação de RNF27 |
| RNF listado na rastreabilidade sem página correspondente | RNF11 aparecia na tabela de rastreabilidade como aplicável a F19, mas a página da feature nunca teve a aba correspondente — só foi percebido numa auditoria manual, não automatizada | Rastreabilidade (tabela) e página de evidências por feature podem divergir silenciosamente; precisa de checagem cruzada periódica entre as duas fontes, não só confiança na tabela central |
| Escopo maior que a capacidade da iteração | CP8 (Sistema de Tickets de Suporte, F22/F23) estava planejado para a IT2 desde o início, mas não coube no tempo disponível após o adiamento do prazo final | Escopo deve ser reavaliado a cada replanejamento de cronograma — CP8 foi removido do escopo da IT2 e fica sem iteração associada até ser replanejado (registrado em 01/07/2026) |
| Permissão granular ignorada em módulos novos | CRM e templates de notificação foram implementados como owner-only, ignorando a matriz de permissões (profiles.permissions) já usada no restante do sistema — só apareceu ao testar com um membro não-owner | Todo módulo novo precisa ser testado com um perfil member (não só owner) antes de ser considerado pronto — permissão granular não é opcional para módulos que reaproveitam uma matriz de permissões já existente |
| Rate limit sem considerar uso normal | O rate limiter de /auth estava configurado de forma agressiva o suficiente para derrubar a sessão de um usuário em uso normal do sistema, não só de um atacante | Limites de segurança (rate limit, lockout) precisam ser validados contra um cenário de uso legítimo intenso antes de ir para produção, não só contra o cenário de ataque que motivou a regra |
| Evidência de formulário nunca virava histórico do lead | A mensagem que o visitante escreve no formulário público de contato nunca era registrada como a primeira interação do histórico do lead no CRM — só a notificação guardava o texto, não a timeline do card | Ao desenhar uma feature que "alimenta" outra (formulário → CRM), verificar explicitamente se cada dado relevante do primeiro fluxo aparece no segundo, não só se o registro principal (o lead) é criado |
| Validação parcial depende da disponibilidade do cliente | O cliente pediu para concentrar toda a validação da IT2 numa única reunião final, por estar num período de alto volume comercial — não houve nenhuma sessão de Partial Client Validation nesta iteração | Partial Client Validation é uma cerimônia assíncrona e depende da disponibilidade do cliente; quando ela não é possível, a ausência deve ser documentada e justificada (não simplesmente omitida), e o cronograma deve sinalizar isso visualmente — ver Partial Validation IT2 |