T-307 - Criar no frontend a área do auditor

• Componente: frontend.
• Depende de: T-304 (contrato), T-306 e T-332 (mockup) e T-305 implantada para a verificação manual.
• Data máxima: 13/11/2026
• Estimativa: 8 pontos (Fibonacci)

Entregável

• Papel de negócio do usuário disponível na sessão, lido do token.
• Entrada da aplicação levando o auditor à área dele e o profissional de RH à nova regra.
• Feature auditoria com a barra lateral do mockup, a tela "Dossiês de regras" e o dossiê da regra com as três abas.
• Aba "Regra e versões" do dossiê.
• Exportação do dossiê.
• Testes da sessão, do redirecionamento, do serviço e das telas.

Descrição

Um auditor que entra no Synapse cai em /nova-regra, e as telas do profissional de RH chamam rotas que lhe respondem 403. Esta tarefa cria a área do auditor sobre as rotas /auditoria/jobs e /auditoria/jobs/{id}, leva cada papel à sua área e entrega a lista de dossiês e o dossiê da regra com a aba "Regra e versões". As outras duas abas e o painel "Todas as operações" vêm na T-336, na T-337 e na T-338.

Contexto e decisões tomadas

• A sessão (src/stores/session.ts) guarda só se o usuário está autenticado. O token do Keycloak, mantido em memória por src/services/keycloak.ts, traz os papéis em realm_access.roles, com exatamente um papel de negócio (profissional-rh ou auditor).
• O papel no frontend serve só para navegação. Quem autoriza é a API.
• A raiz (/) redireciona para /nova-regra em src/features/bootstrap/routes.ts. O logout volta para /nova-regra em iniciarLogout.
• src/router/index.ts não é editado. Rota nova entra no routes.ts da feature, e a restrição por papel fica no beforeEnter das rotas da feature.
• O layout padrão mostra a barra lateral do profissional de RH, que carrega os jobs do próprio usuário. As telas do auditor usam o layout blank e a barra lateral própria do mockup.
• O mockup está na T-306, e a lista de dossiês e os estados das telas, na T-332.
• No vocabulário do mockup, produto é marca, canal é loja e funcionário é cargo. A regra é a única coisa com nome. Loja, marca e cargo aparecem pelo código, as versões pelo número, as entradas, os códigos e as simulações pelo id, e o usuário pelo login. Os identificadores do mockup, como REG-0023, não existem.
• transformarRegra (src/composables/transformarRegra.ts) monta a regra em "SE ... ENTÃO" como o mockup mostra, mas troca o código de loja, marca e cargo pelo rótulo de catalogoRh. A área do auditor mostra o código.
• A exportação salva o JSON de GET /auditoria/jobs/{id} como veio da API. Não há rota de exportação.
• Prompt, resposta, código e texto da entrada são dados não confiáveis. São exibidos como texto, nunca com v-html.
• Uma tela do profissional de RH aberta por um auditor pelo endereço continua recebendo 403 da API. Redirecionar essas rotas fica fora desta tarefa.

Escopo

Dentro do escopo

• src/services/keycloak.ts, src/stores/session.ts, src/features/bootstrap/routes.ts e a feature nova src/features/auditoria/.
• Uma opção em transformarRegra para manter o código, sem mudar o que as telas do profissional de RH mostram.

Fora do escopo

• src/router/index.ts e os arquivos quentes listados em frontend/AGENTS.md.
• Restringir por papel as rotas do profissional de RH.
• Aba "Conversa e Python" (T-336), aba "Simulações e finalização" e comparação de versões (T-337), painel "Todas as operações" (T-338), áudio (T-331), fontes dos dados e modelo da transcrição (T-328).

Requisitos

Sessão e entrada

1. Em keycloak.ts, expor uma função que devolve o papel de negócio do token atual (auditor, profissional-rh ou ausente), lendo tokenParsed.realm_access.roles.
2. Em session.ts, guardar o papel depois de inicializar e limpá-lo em sair e em encerrarPorSessaoInvalida.
3. Em bootstrap/routes.ts, a raiz redireciona o auditor para /auditoria/dossies e os demais para /nova-regra.
4. Em iniciarLogout, o retorno passa a ser a raiz, para que o próximo login leve cada papel à sua área.

Feature auditoria

5. Criar src/features/auditoria/ com routes.ts, types.ts, services/auditoria.api.ts, views/ e components/, conforme src/features/README.md. Os tipos espelham o contrato, e o serviço usa http de @/services/http.
6. Rotas /auditoria/dossies (lista) e /auditoria/dossies/:id (dossiê), com a aba aberta no endereço, para que outra tela abra o dossiê numa aba. As rotas usam meta.layout igual a blank e um beforeEnter que redireciona para a raiz quem não é auditor.
7. A barra lateral mostra "Dossiês de regras", a regra em consulta, o login do auditor e a saída da sessão, conforme o mockup.
8. A lista mostra os jobs paginados de GET /auditoria/jobs, com o nome da regra, o id do job, o login do dono, o status, a origem, as competências, a criação e a finalização, e leva ao dossiê.
9. O dossiê lê GET /auditoria/jobs/{id} uma vez e mostra no cabeçalho o nome da regra, o id do job, o status, o login do dono, os códigos de loja e marca da versão mais recente, a criação e a finalização.
10. A aba "Regra e versões" mostra a entrada inicial (texto, transcrição ou formulário, com o tipo e o horário), a versão mais recente em "SE ... ENTÃO" com os códigos, e o histórico das versões com o número, a origem, o horário, a entrada ou a rodada que a originou e os códigos gerados a partir dela.
11. "Exportar dossiê" salva a resposta de GET /auditoria/jobs/{id} num arquivo dossie-<id do job>.json, sem alterar o conteúdo.
12. Valores vêm prontos da API e só são formatados (data e hora de Brasília, moeda, percentual). Nenhum valor é calculado.
13. Erros mapeiam os códigos sem_permissao e job_nao_encontrado para mensagens da interface, sem exibir o corpo de erro. Os estados de carregamento, erro, lista vazia e acesso negado seguem a T-332.

Observabilidade

14. Falhas das duas chamadas são registradas pelo transporte de telemetria existente, com nome de operação fixo e o código do erro. Nenhum registro inclui prompt, resposta, código, texto da entrada ou o token.

Contexto técnico

• Entradas: token do Keycloak e as respostas das duas rotas.
• Saídas: área do auditor navegável, com a lista de dossiês e o dossiê.
• Componentes afetados: os listados no escopo.
• Restrições: views com até cerca de 200 linhas, com o excedente em composables; Tailwind sem CSS próprio; nenhuma importação entre features.
• Referências: frontend/AGENTS.md, src/features/README.md (frontend/src/features/README.md), frontend/src/stores/session.ts, frontend/src/services/keycloak.ts, bootstrap/routes.ts (frontend/src/features/bootstrap/routes.ts), frontend/src/composables/transformarRegra.ts, historico-jobs (frontend/src/features/historico-jobs/routes.ts) como exemplo de feature com layout blank.

Critérios de aceitação

• Um auditor que abre a raiz chega à lista de dossiês e abre o dossiê de uma regra de outro usuário.
• Um profissional de RH que abre a raiz chega à nova regra, e ao abrir /auditoria/dossies volta para a raiz.
• Um texto de entrada com marcação HTML aparece como texto.
• O logout de um auditor, seguido de novo login, volta à área do auditor.
• O arquivo exportado é igual à resposta de GET /auditoria/jobs/{id}.
• A área do auditor mostra loja, marca e cargo pelo código, e as telas do profissional de RH continuam mostrando o rótulo.

Definição de concluído (DoD)

• make check no frontend sem falha.
• Specs da sessão, do redirecionamento da raiz, do beforeEnter, do serviço, da lista, do dossiê e da exportação.
• Uso no navegador contra a API local com uma conta de auditor e uma de profissional de RH, conferindo os critérios acima e a ausência de requisições a /jobs pela conta de auditor.
• Emissão da telemetria das falhas conferida no navegador; a coleta ponta a ponta é informada como verificação separada.