Pular para o conteúdo

Modelo de Construção (S)

Ponto de vista: IMP — Implementação


A codificação deverá ser realizada por IA agêntica especializada, com papeis definidos, segregação de responsabilidades e contexto controlado.

Cada agente opera com escopo delimitado — sem acesso irrestrito ao repositório. Decisões de arquitetura, segurança e integração permanecem com o Validador Técnico humano.


Os testes deverão ser produzidos e executados por IA agêntica, abrangendo:

TipoQuando
Testes unitáriosToda função ou método isolável
Testes integradosInteração entre módulos e serviços
Testes funcionaisComportamento esperado conforme as histórias
Testes estruturaisQualidade do código, complexidade, padrões
Testes de regressãoA cada alteração em componente existente
Testes de cargaPara componentes com SLA definido na INFHDISP
Testes de segurançaSAST, DAST e testes de dependências
Testes de operaçãoComportamento em ambiente de produção simulado

Cobertura mínima no Modo Completo: ≥ 80%.


Em legado ou contextos onde testes automatizados ou de caracterização não forem viáveis de imediato, o framework não dispensa evidência: o órgão deve registrar como a mudança foi verificada e qual risco residual permanece até a maturação da suíte de testes.

Exemplos de substitutos aceitáveis quando a política do órgão assim permitir (sempre com registro em evidências da IMP e, se aplicável, vínculo à história):

  • reprodução em ambiente de homologação alinhado ao especificado em HAMB / HSIS;
  • roteiro de teste manual ou checklist assinado pelo Validador Técnico ou papel equivalente;
  • evidência de monitoração ou comparação de comportamento antes/depois, quando couber na OBS / RUN.

Esses substitutos não substituem a especificação em HAUT para evolução do pipeline: a meta permanece automatizar verificação na medida do possível. O encaixe com chamados na sustentação está em SIS — encaixe com atendimento de chamado.


A validação de alucinação da implementação deverá ser feita por outra engine de IA em contexto distinto, buscando chegar ao mesmo resultado por caminho diverso.


A qualidade deverá ser avaliada por IA agêntica, considerando:

  • aderência às histórias aprovadas
  • conformidade com a arquitetura definida
  • padrões de código e complexidade
  • cobertura de testes
  • documentação inline
  • prontidão operacional

  • Defeito antes do DOD: tratado no ciclo normal de PR e pipeline — não constitui nova história; mantém-se o vínculo ao ID da história ESP nos commits.
  • Defeito com história já em implementado: segue as regras de DOD — retrabalho e reabertura e a decisão documentada de reabrir a mesma história ou registrar demanda corretiva ligada à história — ver Tipos de Demanda.
  • Lead time (tempo da entrega): quando o órgão exigir métrica de prazo, a fonte auditável é a data dos registros em evidências (ESP/04-evidencias/, IMP/04-evidencias/) e os timestamps de pipeline e merge — sem novo conceito no framework.

Quando a lacuna for entre especificação aprovada e o que se pretende codificar (antes de divergência entre engines), aplique Desvio controlado da especificação — nota provisória, classificação de impacto e RFC/IRA quando obrigatório.