[Unificação] Eliminar tela Simulados admin + vista interna no ShowProva + cleanup criarSimulado

[FernandoAlmeidaPinto]

Resumo da entrega. 6 cards no total. Consolida a admin em uma única tela (Provas), move a visualização dos simulados pra dentro do modal de detalhes da prova, e limpa a permissão legada criarSimulado — corrigindo o label enganoso que apresentava ela como "Visualizar Simulados".

Documento de fundação: docs/unificacao-simulados-provas.md
Posição na série: 2 de 10

---

Por que essa etapa

Hoje o admin tem duas entradas independentes no menu ("Simulados" e "Provas") que tratam do mesmo domínio. A tela DashSimulado é puramente contemplativa — cards não são clicáveis, não há navegação, não há ação. Ela existe só pra "olhar a lista". Isso é redundante: a lista de simulados de uma prova faz muito mais sentido dentro do contexto daquela prova.

Além disso, existe uma permissão legada chamada criarSimulado que na UI é apresentada com o label "Visualizar Simulados" (RolesLabel em roles.ts). É lixo do sistema que confunde qualquer dev novo lendo o código, e mais um item pra manter alinhado quando o modelo de permissões evolui.

Essa etapa elimina a tela Simulados, move a lista de simulados de uma prova pra dentro do ShowProva modal (via state switch entre details e simulados), e faz o cleanup completo do criarSimulado preservando acesso de quem tinha essa permissão (migração automática pra visualizarProvas).

Decisões cravadas

• Deletar pages/dashSimulado/index.tsx e a entrada correspondente do menu admin.
• Adicionar state view: 'details' | 'simulados' no ShowProva — sem sub-modal, sem drawer, sem componente novo.
• Carregar prova com simulados[] populado via getProvaById no useEffect do modal.
• Tabela compacta pros simulados (não cards) — usa melhor o espaço horizontal.
• Remover Permissions.criarSimulado e todos os seus 14 usos mapeados.
• Antes do drop da coluna, rodar SQL UPDATE roles SET visualizar_provas = TRUE WHERE criar_simulado = TRUE AND visualizar_provas = FALSE — ninguém perde acesso.
• Não confundir com visualizarSimulado — essa permissão não existe no código (confirmado por grep). Registrado no doc §8.2 como "não deve ser criada no futuro".
• Comunicar admins via release notes: "A permissão 'Visualizar Simulados' virou 'Visualizar Provas'".

Pré-requisitos

• [Categoria] concluída e em produção. Necessário porque:
  • Prova.exame foi removido; a vista de detalhes agora lê prova.categoria.exame.nome.
  • Simulado.tipo virou Simulado.categoria; a tabela de simulados lê categoria.nome.

Cards desta etapa

Ordem obrigatória por dependência: 04 → 05 → 06 (cleanup do criarSimulado).
Frontend da unificação (01, 02, 03) pode ir em paralelo com 04-05-06 desde que:

• Card 03 (vista interna) precisa do Card 02 (service + DTO).
• Card 01 (remover DashSimulado) é independente e pode ir primeiro sem risco.

• Card 01 · client-vcnafacul · Remover DashSimulado (tela + rota + entrada do menu)

  • Deleta tela, remove rota e a entrada "Simulados" do menu admin. O gate criarSimulado da rota vai junto (o restante do cleanup é nos cards 05-06).
  • Estimativa: S

• Card 02 · client-vcnafacul · Service getProvaById + DTO Prova com simulados

  • Cria service que consome GET /mssimulado/prova/:id (endpoint já popula simulados+categoria+questoes no backend). Estende tipo Prova com simulados?: SimuladoResumo[].
  • Estimativa: S
  • Bloqueia: 03

• Card 03 · client-vcnafacul · Vista interna no ShowProva (detalhes + simulados)

  • State-based view switch (details / simulados). useEffect com fetch. Tabela com nome/categoria/questões/status. Loading / empty / error tratados. Race condition mitigada com cancelled flag.
  • Estimativa: M
  • Bloqueado por: 01, 02

• Card 04 · api-vcnafacul (scripts) · SQL: preservar acesso antes de remover criar_simulado

  • Roda antes do Card 05. UPDATE roles SET visualizar_provas = TRUE WHERE criar_simulado = TRUE AND visualizar_provas = FALSE. Blinda contra perda de acesso (recorrente da armadilha do label enganoso).
  • Estimativa: XS
  • Bloqueia: 05

• Card 05 · api-vcnafacul · Remover criarSimulado (backend cleanup)

  • Remove do enum Permissions, @Column da entity, DTO, service (3 refs), seeds. Migration TypeORM DROP COLUMN. Migra guard do DELETE /mssimulado/simulado/:id pra cadastrarProvas. Investiga e limpa o POST /mssimulado/simulado legado (pendência §2.2).
  • Estimativa: M
  • Bloqueado por: 04
  • Bloqueia: 06

• Card 06 · client-vcnafacul · Remover criarSimulado (frontend cleanup) + release notes

  • Remove do enum Roles, do RolesLabel (a entrada com label enganoso "Visualizar Simulados"), do DTO createRole, e dos 2 ModalNewRole. Rascunha release notes pra time interno.
  • Estimativa: S
  • Bloqueado por: 05

Coordenação de deploy

Ordem obrigatória:

1. Backup do banco MySQL do api-vcnafacul (padrão do time).
2. Rodar Card 04 (SQL) — validação prévia + UPDATE + validação pós (roles_ainda_impactadas = 0).
3. Deploy do api-vcnafacul (Card 05) — TypeORM migration executa o DROP COLUMN na inicialização.
4. Deploy do client-vcnafacul (Cards 01, 02, 03, 06 — pode ser 1 release ou 2, contanto que 06 vá depois do 05 ficar em prod).
5. Postar release notes logo após o deploy do frontend.

Se preferir dividir Cards 01-03 (unificação) e 04-06 (cleanup permissão) em dois deploys separados: também funciona. A unificação frontend é totalmente compatível com o backend legado que ainda tem criar_simulado.

Riscos consolidados

• Cleanup do criarSimulado sem rodar Card 04 antes → admins que dependiam do label "Visualizar Simulados" perdem acesso ao ver simulados. Mitigado por ordem obrigatória + AC do Card 05 exige evidência do Card 04.
• Migration TypeORM sem backup = irreversível. Backup padrão obrigatório.
• Race condition no ShowProva (abrir/fechar rápido) → cancelled flag no useEffect blinda.
• Bookmarks de /dashboard/dash-simulado viram 404. Decisão consciente, sem mitigação — comunicar internamente se surgirem reclamações.
• Simulado com categoria não populada (edge case pré-migração da etapa 1) → defensive simulado.categoria?.nome ?? '—' na tabela. Como [Categoria] já foi pra prod, esse cenário é improvável.

Próximas etapas

Depois de [Unificação]:

• [CRUD Categoria] (etapa 3) — vem em seguida naturalmente; pluga um botão "Gerenciar Categorias" na DashProva que este doc deixou o slot preparado.
• [Questão Multi-Prova] (etapa 9, Release A.5) — refactor profundo que pode intercalar aqui se a decisão for executar cedo. Consulte docs/resumo-time.md pra ordem consolidada.

Referências

• Doc completo de design: docs/unificacao-simulados-provas.md
• Resumo executivo de toda a série: docs/resumo-time.md
• Pendências vivas: docs/pendencias.md (§2.2 relevante pra esta etapa)