T-074 - Implementar a tela de confirmação do núcleo

[pedro-fs-garcia]

T-074 - Implementar a tela de confirmação do núcleo

• Componente: frontend

• Estimativa: 3

• Depende de: T-005

• Data máxima: 2026-09-22 (ter)

Descrição

Implementar a tela de confirmação que exibe cada campo do núcleo individualmente e editável, bloqueando o avanço enquanto houver campo obrigatório ausente, e confirma via POST /jobs/{id}/parameters.

A tela de confirmação existe nas duas primeiras sprints, com pesos diferentes. Na Sprint 1 ela é uma revisão do que o próprio usuário digitou; na Sprint 2 passa a validar uma extração inferida, com correção de interpretação errada e registro na trilha (US-006).

O que se entrega agora é a estrutura: exibir cada elemento individualmente, permitir edição e bloquear o avanço enquanto houver pendência.

Escopo

Dentro do escopo

• Exibição de cada campo do núcleo, individualmente e de forma legível, reutilizando os componentes de T-070.
• Edição manual dos campos antes de confirmar.
• Destaque de campo obrigatório ausente e bloqueio do avanço.
• Confirmação via POST /jobs/{id}/parameters.

Fora do escopo

• Exibição de elementos além do núcleo (Sprint 2), embora a tela deva acomodá-los sem redesenho.
• Paráfrase da regra em linguagem natural, que faz sentido quando houver extração inferida.
• Registro da correção na trilha como requisito da US-006 - a api já registra a edição (T-041); a exigência de auditoria é da Sprint 2.
• Verificação de coerência (T-052), que é do codegen e acontece depois.

Requisitos

• Cada elemento é exibido individualmente; nada de bloco único de JSON ou resumo em texto corrido.
• Campo obrigatório ausente bloqueia o avanço, com a pendência marcada no campo.
• A edição aqui gera nova versão da representação - comportamento garantido pela API (T-041), que a tela precisa refletir corretamente ao recarregar.
• A tela não valida coerência entre elementos: isso é do codegen, e o conflito volta como mensagem.

Contexto técnico

• Entradas: representação do job via GET /jobs/{id}; endpoint de confirmação (T-041); componentes de campo (T-070).
• Saídas: tela de confirmação; parâmetros confirmados enviados à API.
• Componentes afetados: frontend/.
• Restrições: o usuário-alvo não domina tecnologia; a tela precisa deixar claro o que ele está confirmando e o que acontece a seguir.
• Referências: ARCHITECTURE.md §3.1 (validação de parâmetros), §2.3 (a tela nas duas sprints) e §1.5.

Critérios de aceitação

• A tela exibe cada campo do núcleo individualmente e de forma editável.
• Campo ausente é destacado e bloqueia o avanço.
• Confirmar envia a POST /jobs/{id}/parameters e leva à tela de acompanhamento.
• Editar e confirmar de novo mostra os valores da versão mais recente ao recarregar.
• Um conflito devolvido pelo codegen é exibido apontando o elemento, não como erro genérico.
• A tela reutiliza os componentes de campo de T-070.

Definição de concluído (DoD)

• Todos os critérios de aceitação foram atendidos.
• Testes automatizados foram adicionados ou atualizados quando aplicável.
• Os testes existentes passam.
• O código segue as convenções e padrões de qualidade do projeto.
• Documentação, migrações, contratos ou configurações exigidos foram atualizados.
• Nenhuma regressão conhecida ou problema não resolvido foi introduzido pela tarefa.
• As alterações foram confirmadas e estão prontas para revisão/mesclagem.
• A implementação foi verificada no ambiente apropriado.

Observações / Decisões

Fronteira com T-070, declarada: T-070 é o formulário de entrada, T-074 é a revisão antes de simular. As duas exibem os mesmos campos, e por isso os componentes vêm de T-070 - reimplementá-los daria duas apresentações divergentes do mesmo dado.

Explicabilidade ex ante: esta tela é onde o usuário vê o entendimento do sistema e corrige antes que ele produza qualquer valor. Na Sprint 1 isso é quase trivial; na Sprint 2 é a principal defesa contra erro de interpretação.