Pular para conteúdo

AUR-512 — Repositório consumidor prova instalação, review e falhas

Medido antes (por leitura)

  • Não havia tests/consumer; a prova do produto era o self-review deste repositório (code-review.yml), que o card recusa como prova isolada.
  • O produto já tem as peças a observar: workflow reutilizável (review.yml), Action direta (action.yml), status aurumcode/review e aurumcode/policy-gate, marcador <!-- aurumcode-review --> nos comentários, e o check Changelog obrigatório (AUR-509).

Decisão

  • tests/consumer/cenarios.json: onze cenários, cada um com fixture (fixtures/), workflow do consumidor (workflows/, sempre pinado por AURUMCODE_SHA, nunca @main nem pull_request_target) e expectativa (conclusão, status/checks, idioma, modo, sugestão inline, teto de comentários, texto). pr-de-fork é manual.
  • tests/consumer/run.sh (bash, git, gh, jq; nenhum Go no host): dirige as PRs no consumidor e grava a evidência por cenário. Usa só a identidade git já configurada; para sem ela. Nunca escreve na main do consumidor.
  • tests/consumer/consumer.go: verificador puro (pacote Go consumer) que compara evidência e expectativa; nao_medido exige limitação e nunca aprova; evidência sem repo, SHA ou run reprova.
  • docs/qa.md: seção "QA no repositório consumidor (AUR-512)".

Como cada cenário é provado (tests/acceptance/AUR-512.sh)

  • AC-001..AC-003: TestAUR512ScenarioTableCoversTheContract (modos, inline, Action direta e workflow reutilizável pinados, falhas do AC-002, fork declarado, sem pull_request_target).
  • AC-004: TestAUR512RegressedProductFailsQA (changelog ausente que passou, SQL que passou, rodada que dobrou comentários e correção que não limpou o bloqueio reprovam o QA).
  • AC-005: TestAUR512EvidenceIdentifiesTheRunAndInfraIsNotMeasured; com AURUMCODE_QA_EVIDENCIA, o mesmo teste verifica a evidência real.
  • MUT-001: o verificador deixa de olhar conclusão e status; o produto regredido passa e TestAUR512RegressedProductFailsQA fica vermelho.

Limites

  • Nada foi executado contra um consumidor nesta entrega: a evidência real é da rodada do dono (billing, secrets e repositório consumidor são dele).
  • O fork exige uma segunda conta: o cenário fica nao_medido até alguém fornecer a evidência.
  • Os testes usam evidência sintética, montada em memória a partir das expectativas: provam o verificador, nunca o produto.