Prompt para Especificação de Batch Delete de Conversas

Você é um designer de produto e engenheiro de software. Crie uma especificação completa para a funcionalidade de apagar várias conversas de uma vez (batch delete) em um app de chat. O objetivo é permitir aos usuários selecionar múltiplas conversas com uma checkbox, confirmar a deleção e remover as conversas de forma segura. A saída deve incluir: visão geral, objetivo, user stories, requisitos funcionais e não funcionais, critérios de aceitação com exemplos Given When Then, fluxos do usuário, wireframes textuais, API endpoints e modelo de dados, alterações de banco de dados, estratégia de deleção (soft delete vs hard delete) e retenção de dados, considerações de privacidade e auditoria, acessibilidade, internacionalização, segurança, desempenho, testes, métricas e monitoramento, plano de migração e rollback, exemplos de payloads e respostas, e um pseudocódigo de backend. Instruções adicionais: mantenha o conteúdo claro, forneça exemplos práticos, inclua mensagens de interface sugeridas, e liste edge cases e limitações. 

Visão geral: descreva o problema, o impacto na experiência do usuário e os objetivos de negócio. 
Objetivo: permitir deleção em lote com confirmação, desfazer ação, e manter trilha de auditoria. 
User stories: 
- Como usuário quero selecionar várias conversas para deletar de uma vez para economizar tempo. 
- Como usuário quero confirmar a deleção para evitar remoções acidentais. 
- Como administrador/inspector quero ver logs de deleção para auditoria. 
Requisitos funcionais: 
- Seleção múltipla com checkbox ou modo de seleção em massa. 
- Botão de Delete ativo apenas quando pelo menos uma conversa está selecionada. 
- Confirmação de deleção com mensagem de confirmação e opção de Undo. 
- Exclusão marcada como soft delete com campo deletedAt e possivelmente um flag isDeleted. 
- Possibilidade de restaurar itens dentro de um período de retenção. 
- Atualizar contagem de conversas visível ao usuário. 
- Logs de auditoria com usuário, timestamp e IDs de conversas apagadas. 
Requisitos não funcionais: 
- Desempenho: suporte a deleção de até N conversas simultaneamente sem impacto perceptível no UX. 
- Confiabilidade: operação atômica por lote com rollback em caso de falha. 
- Segurança: validações de permissão, autenticação e rate limiting para operações de bulk delete. 
Critérios de aceitação (exemplos Given/When/Then): 
- Dado que várias conversas estão selecionadas, quando o usuário confirmar a deleção, então as conversas devem ser marcadas como apagadas e removidas da lista visível. 
- Dado que uma deleção é realizada, quando houver erro de backend, então o usuário deve ver mensagem de erro e a ação deve ser revertida. 
- Dado que a deleção é feita, quando a opção de Undo estiver disponível, então o usuário pode restaurar as conversas dentro do período de retenção. 
Fluxo do usuário: seleção -> selecionar todas -> confirmar deleção -> confirmação adicional (undo) -> atualização da tela. 
Wireframes textuais (descrições de layout): 
- Barra de ações no topo com botão Select All, Delete e Cancel. 
- Lista com caixas de seleção ao lado de cada conversa e indicador de status (apagada/ativo). 
- Caixa de diálogo de confirmação com opção de Undo após a deleção. 
API e modelo de dados: 
- Endpoints sugeridos: 
  - POST /conversas/batch-delete com corpo { conversation_ids: ["id1","id2"], user_id: "...", reason?: "..." } 
  - POST /conversas/{id}/restore para restaurar uma conversa.
  - GET /audit/logs?filter=deletion&since=... 
- Modelo de dados: Conversa com campos id, owner_id, createdAt, updatedAt, deletedAt (null se ativo), isDeleted (boolean). 
- Mensagens de resposta de sucesso/falha com códigos HTTP apropriados. 
Alterações de banco de dados: 
- Adicionar campo deletedAt e isDeleted na tabela de conversas. 
- Criar índice em deletedAt para consultas de visualização eficiente. 
- Endpoints de batch delete devem operar dentro de uma transação quando possível. 
Estratégia de deleção: soft delete vs hard delete: 
- Recomenda-se soft delete com deletedAt para possibilitar restauração e auditoria, seguido de políticas de retenção para deleção permanente após período definido. 
Privacidade, conformidade e auditoria: 
- Registrar quem deletou, quando e quais IDs foram deletados. 
- Explicar opções de retenção de dados, conformidade com LGPD/ GDPR conforme aplicável. 
Acessibilidade: garantir que o fluxo seja utilizável por leitores de tela, com labels claros e feedback de status. 
Internacionalização: preparar mensagens de UX para i18n com placeholders dinâmicos. 
Segurança: autenticação, autorização, validação de input, proteção contra CSRF, rate limiting, logs de segurança. 
Desempenho e escalabilidade: considerar paginacao/virtualização da lista para grandes volumes de conversas e operações de bulk. 
Testes: 
- Unit tests para validação de payloads e regras de negócio. 
- Integration tests para endpoints de batch delete. 
- End-to-end tests simulando fluxo de usuário com seleção, deleção e restauração. 
Métricas e monitoramento: tempo de bulk delete, falhas, taxa de sucesso, volumes de dados manipulados, tempo de restauração. 
Plano de migração e rollback: 
- Planejar upgrade de esquema com downtime mínimo, migração de dados para novos campos e rollback suave. 
Exemplos de payloads e respostas: incluiram payloads de deleção e de restauração com estruturas JSON. 
Pseudocódigo de backend: 
- Validar permissões e obter conversa a partir de IDs fornecidos. 
- Iniciar transação; marcar cada conversa como deletada definindo deletedAt; registrar logs de auditoria; confirmar transação; retornar sucesso ou falha. 
Mensagens de interface sugeridas: Confirm Deletion, Deletion successful, Undo available, Deletion failed, Restored successfully. 
Casos de edge cases: 
- Usuário sem permissão para algumas conversas selecionadas. 
- Interrupção de rede durante a operação. 
- Tamanho de lote muito grande exigindo chunking. 
- Itens já deletados ou em estado inconsistente. 
- Restaurar após o período de retenção. 
Limitações: escopo atual pode não suportar restauração de itens com certos metadados; considerar futuras extensões para filtros de exclusão e políticas de retenção.