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 INF — HDISP
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.