Pular para conteúdo

AUR-309 — caracterização do pipeline legado

Documento histórico do board. Pode descrever componentes removidos; para uso atual, consulte o guia do produto.

Contrato

Este card caracteriza o comportamento observável de internal/pipeline/extractor_pipeline.go sem alterar o pacote legado. A suíte recompila esse arquivo de produção byte a byte e executa seus entrypoints em um módulo temporário. As dependências downstream que não pertencem aos read_paths são doubles instrumentados e card-scoped: registram chamadas, escrevem somente no diretório temporário e não acessam rede, Git, indexadores ou publicadores.

Uma linha só recebe reachable depois que a chamada ou o efeito nomeado foi observado durante a execução. deployToGHPages recebe stub/unreachable porque a branch habilitada é realmente alcançada, o log de placeholder é observado e nenhuma chamada de deploy, Git ou publicação é registrada. Presença de função, nome de arquivo e grep de fonte não classificam comportamento.

O relatório canônico é ordenado por entrypoint e contém exatamente estas colunas:

entrypoint<TAB>classification<TAB>effect

As classificações permitidas são reachable e stub/unreachable. O fixture tests/characterization/legacy/pipeline/expected.tsv sela 13 entrypoints ou fases observáveis e seus efeitos. O acceptance compara bytes do relatório executado com esse fixture; linhas ausentes, extras, duplicadas ou divergentes saem 1.

Camadas executáveis

  • TestAUR309 executa os entrypoints de erro e prova redaction e Unwrap.
  • ContractAUR309 executa o pipeline e valida cardinalidade, unicidade, classificações e a fronteira do stub de deploy.
  • IntegrationAUR309 executa os caminhos full, incremental, skip, scaffold, welcome e Jekyll, emitindo uma linha por efeito realmente observado.
  • E2EAUR309 chama o acceptance pelo selector de integração e exige o marcador de sucesso produzido somente depois da comparação canônica.

Cada arquivo .go declarado pelo card é copiado para um pacote de teste temporário junto do arquivo de produção e recebe uma bridge *_test.go; assim o selector citado é uma função executada por go test, não um nome aceito sem asserções. A tag aur309_characterization isola os fontes instrumentados do build normal e é habilitada explicitamente pelo acceptance. GOPROXY=off, GOSUMDB=off e GOTOOLCHAIN=local impedem resolução de dependências. O pequeno double de YAML é fornecido via vendor; go.mod e go.sum são copiados sem edição e permanecem os inputs canônicos do card.

Limites e segurança

  • stdout e stderr de cada camada: entre 1 byte e 32 KiB;
  • stdout e stderr do wrapper OCI: limitados pelo profile a 64 KiB cada;
  • 13 observações exatas, sem entrada livre no JSON final;
  • temporários com umask 077 e remoção por trap;
  • nenhuma indexação real, rede, socket, mount, device, capability ou publicação;
  • AURUM_SECRET_CANARY, quando presente, é rejeitado antes de qualquer log de camada ser mostrado;
  • os efeitos de filesystem ficam sob t.TempDir() ou sob o tmpfs do runner.

O JSON final é uma observação sanitizada para captura pelo coordenador em .board/evidence/AUR-309/acceptance/AC-001.json. Ele inclui digests SHA-256 da árvore materializada, de internal/pipeline, dos testes e do relatório, além das 13 classificações. O acceptance não escreve nem aprova evidence.

Exemplo executável

./.board/bin/oci-run --profile bootstrap-readonly-v1 --card AUR-309
bash tests/acceptance/AUR-309.sh TestAUR309
bash tests/acceptance/AUR-309.sh ContractAUR309
bash tests/acceptance/AUR-309.sh IntegrationAUR309
bash tests/e2e/AUR-309.sh E2EAUR309

O primeiro comando é o acceptance oficial. Os demais são seletores de diagnóstico e devem terminar com exit 0 quando executados num ambiente Go+Bash equivalente ao profile pinado.

MUT-001

Trocar, no fixture esperado, a classificação de deployToGHPages de stub/unreachable para reachable simula a alegação de funcionalidade sem chamada registrada. O mesmo wrapper oficial deve sair 1 e emitir exatamente:

AUR-309/AC-001/MUT-001

Depois de restaurar o byte original, o wrapper volta a sair 0. Falha de build, loader, ferramenta, imagem ou container é inconclusiva e não conta como RED da mutação.

Falhas e diagnóstico

  • exit 0: todas as camadas executaram asserções reais e o relatório coincidiu;
  • exit 1 com MUT-001: um stub sem chamada foi rotulado funcional;
  • exit 1 com characterization_mismatch: chamada, efeito, ordem ou cardinalidade divergiu do baseline;
  • exit 1 com <layer>_exit:<n>: a função de teste real falhou;
  • exit 64: selector desconhecido;
  • exit 79: ferramenta ou preparação do harness indisponível; nunca é RED comportamental.

O diagnóstico é bounded. Logs de Go só são mostrados em falha depois da verificação do canary e no máximo nas primeiras 80 linhas.

Compatibilidade, migração e rollback

internal/pipeline, go.mod e go.sum são somente leitura e devem permanecer byte a byte iguais. A caracterização é o estado before para os cards futuros de reconstrução; este card não migra nem remove código. Rollback consiste em reverter somente os paths do AUR-309 e repetir AC-001. Nenhum efeito externo novo precisa ser desfeito.