T-070 - Implementar tela do formulário de regra no frontend

[pedro-fs-garcia]

T-070 - Implementar tela do formulário de regra no frontend

• Componente: frontend

• Estimativa: 5

• Depende de: T-005, T-071

• Data máxima: 2026-09-16 (sex)

Descrição

Implementar a tela de formulário com os campos do núcleo e o campo de orçamento, submetendo a POST /jobs com origem formulario de acordo com a referência no mockup: https://github.com/Titus-System/synapse/issues/69#issue-5382135790

A porta de entrada do usuário até a Sprint 2. Campos fixos do núcleo, mais dois parâmetros da simulação que não são da regra: a competência de referência - qual mês histórico recalcular - e o orçamento de comissionamento.

A limitação da Sprint 1 está no que pode ser informado, nunca no que é simulado daquilo que foi informado.

Referência

Escopo

Dentro do escopo

• Campos do núcleo, conforme o vocabulário fechado em T-084.
• Seleção do intervalo de competência entre as 6 disponíveis.
• Campo de orçamento, com formatação monetária.
• Validação client-side de presença e formato, complementar à da API.
• Submissão a POST /jobs com origem formulario.
• Componentes de campo reutilizáveis pela tela de confirmação.

Fora do escopo

• Tela de confirmação (T-074), que reutiliza os componentes de campo daqui em modo de revisão.
• Captura de voz e texto livre (US-002, Sprint 2).
• Elementos da regra além do núcleo, que a Sprint 2 permitirá informar.
• Acompanhamento após a submissão (T-073).

Requisitos

• A validação client-side não substitui a da API: serve para reduzir round-trips óbvios.
• Campo do núcleo vazio bloqueia o envio, com a pendência visível no campo, não numa mensagem geral.
• O usuário-alvo "não tem domínio de tecnologia": rótulos e mensagens em linguagem de negócio, sem jargão.
• O frontend não calcula nada - nem prévia de custo, nem validação de orçamento contra valor esperado.

Contexto técnico

• Entradas: openapi.yaml (T-005); cliente REST e sessão (T-071); vocabulário do núcleo (T-084).
• Saídas: tela de formulário; job criado ao submeter; componentes de campo reutilizáveis.
• Componentes afetados: frontend/.
• Restrições: acessibilidade e clareza são requisito não funcional do parceiro; as seis competências são fixas e conhecidas.

Critérios de aceitação

• O formulário coleta todos os campos do núcleo, mais competência e orçamento.
• A competência é escolhida entre as seis disponíveis, sem entrada livre.
• Campo do núcleo vazio bloqueia o envio, com a pendência marcada no próprio campo.
• Submeter cria o job e leva à tela de acompanhamento.
• Um erro de validação vindo da API destaca o campo correspondente.
• Nenhum valor exibido é calculado pelo frontend.
• Os componentes de campo são exportados para uso em T-074.

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-074, declarada: os componentes de campo nascem aqui e são reutilizados lá em modo de revisão. Duas telas exibem os mesmos campos do núcleo, e reimplementá-los daria duas apresentações divergentes do mesmo dado.

Efeito cascata recebido: depende do vocabulário de T-084 pela via de T-004 e T-005. Se o núcleo mudar, este formulário muda com ele.