feat: Automation Contract v1.2 -- múltiplos passos por resultado e outcome CONDITIONAL_PASS #75
Loading…
Reference in a new issue
No description provided.
Delete branch "feature/automation-contract-v1.2-multistep"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Implementa o P1 "múltiplos TestRunStep por resultado" do backlog, com escopo confirmado com o usuário antes de implementar (existe necessidade real e concreta: validação de manufatura, em desenho agora).
Granularidade explícita (
steps):AutomationResultInganha um campo opcionalsteps-- uma ação por item, cada uma com seu própriooutcome/duration_ms/failure_classification/message/evidence/metrics, na ordem enviada. Semsteps, comportamento idêntico ao que já existia (1 passo sintético a partir do result) -- 100% aditivo, nenhum payload v1/v1.1 muda de comportamento.Novo outcome
CONDITIONAL_PASS("aprovado com ressalvas") -- decisão explícita do usuário de deixar como vocabulário compartilhado entre automação e execução manual (schemas.StepOutcome), não restrito só à ingestão. Precedência definida emservices/scenario_status.aggregate_scenario_status(entrePENDINGe oPASSdefault). UI atualizada: dropdown de status de passo,StatusBadge(variantwarning), card de contagem emRunDetail.tsx, stories do Storybook.Decisão de produto explícita (confirmada com o usuário): o
outcomede um result nunca é recalculado a partir do "pior status vence" dossteps-- quem chama a API decide o veredito final do caso de teste, mesmo que um passo individual tenha falhado (é assim que fica viável reportarCONDITIONAL_PASScom um passoFAILdentro, ex.: desvio de manufatura formalmente aceito).Achado real ao implementar: essa decisão quebraria
_dedup_response(contavaoutcome_countspor passo, não por result -- divergia do que a ingestão original reportava assim que um result passa a ter mais de 1 passo). Corrigido comTestRunScenario.automation_outcome(novo campo, só preenchido por ingestão de automação), migration1e03ec5658f9-- e travado em teste (test_deduplicated_reingestion_of_multistep_result_reports_consistent_outcome_counts).Verificação: backend 266/266 testes (10 novos: multi-step em ordem, outcome não-recalculado, dedup consistente, CONDITIONAL_PASS aceito, precedência de agregação); migration testada upgrade→downgrade→upgrade +
alembic checksem drift; frontendtsc/lint/154 testes/build limpos; verificado manualmente ponta a ponta no dev server local (ingestão via curl + edição manual na UI + persistência após reload, com screenshot).🤖 Generated with Claude Code
Motivado por uma necessidade real (validacao de manufatura, em desenho agora): AutomationResultIn ganha um campo opcional `steps`, permitindo reportar varias acoes por caso de teste (cada uma com seu proprio outcome/duration_ms/failure_classification/message/evidence/metrics) em vez do unico passo sintetico do v1/v1.1. Sem `steps`, comportamento identico ao que ja existia. Novo outcome CONDITIONAL_PASS ("aprovado com ressalvas") -- vocabulario compartilhado entre automacao e execucao manual (schemas.StepOutcome), decisao explicita do usuario. O outcome de um result nunca e recalculado a partir do "pior status vence" dos steps -- quem chama a API decide o veredito final. Isso exigiu TestRunScenario.automation_outcome (migration 1e03ec5658f9) pra _dedup_response nao divergir do outcome_counts da ingestao original quando um result tem varios passos. Verificado manualmente na UI (dev server local): ingestao multi-step + CONDITIONAL_PASS, edicao manual de um passo pra CONDITIONAL_PASS, e persistencia apos reload -- tudo funcionando ponta a ponta. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>