Pular para conteúdo

AUR-004: validar DAG e liberar dependências

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

Comportamento

internal/governance/dag.Release valida um snapshot completo antes de responder. Uma aresta para card ausente, um ciclo, uma transição fora da máquina de estados ou um evento de aprovação que se apresenta como agente retorna *dag.ValidationError; nenhum resultado parcial é liberado. Em caso válido, a resposta contém a ordem topológica estável e somente os cards que já estão em ready e cujas dependências já estão em done.

A consulta é pura: não escolhe worker, não executa acceptance, não altera lane, não autentica pessoas e não publica estado. Eventos de autorização são entradas pré-verificadas pelo boundary chamador. Mesmo um evento humano válido não muda o status de uma dependência; identidade de agente é recusada e nunca concede uma exceção.

Contrato

  • schema é aurum.dag-release-query, version é 1 e a identidade é um digest sha256: minúsculo de CandidateIdentityV1.
  • IDs seguem AUR-NNN; cards, dependências e eventos são limitados a 64 e não aceitam duplicatas.
  • Estados aceitos: backlog, ready, doing, review, validating, done, blocked-on-owner e cancelled. Permanecer no mesmo estado é válido; os demais movimentos usam a tabela fechada descrita no código.
  • A ordenação usa desempate lexicográfico. releasable é uma consulta imediata, não um plano futuro: uma dependência em ready continua bloqueando o card.
  • O artifact digest cobre schema, versão, CandidateIdentityV1, ordem, releasable e effects: 0. Repetir os mesmos bytes reproduz ordem, saída, exit code e digest.

Limites e erros

O harness aceita no máximo 64 vetores, 4 MiB de fixture e deadline declarado de 1 a 30 segundos. A API limita 64 cards, 64 dependências por card e 64 eventos. Erros são rótulos estruturais sanitizados: invalid_query, limit_exceeded, duplicate_card, duplicate_dependency, missing_dependency, cycle, invalid_status, illegal_transition, agent_identity_forbidden e invalid_authorization. Valores hostis não são repetidos na mensagem.

Exemplo executado

O bloco entre os marcadores é carregado e executado por IntegrationAUR004; sua única liberação é AUR-002.

{"schema":"aurum.dag-release-query","version":1,"candidate_identity":{"digest":"sha256:2222222222222222222222222222222222222222222222222222222222222222"},"cards":[{"id":"AUR-001","previous_status":"done","status":"done","depends_on":[]},{"id":"AUR-002","previous_status":"backlog","status":"ready","depends_on":["AUR-001"]}],"authorization_events":[]}

Diagnóstico

Execute primeiro tests/acceptance/AUR-004.sh TestAUR004 e depois tests/acceptance/AUR-004.sh IntegrationAUR004. Exit 64 significa selector desconhecido; 69 indica infraestrutura ou compilação e não é RED comportamental; 1 com AUR-004/AC-001/... é uma divergência alcançada após o entrypoint. O gate externo permanece exatamente ./.board/bin/oci-run --profile bootstrap-readonly-v1 --card AUR-004.

MUT-001 deve tornar uma aresta cíclica aceitável e ser detectada como AUR-004/AC-001/MUT-001. MUT-002 deve permitir a identidade de agente e ser detectada como AUR-004/AC-001/MUT-002. Após cada restauração, a aceitação deve voltar ao mesmo exit e artifact digest. O canário AURUM_SECRET_CANARY nunca entra em output, cache ou evidência.

Rollback reverte somente os paths de AUR-004 e repete AC-001; não há migração nem estado externo para desfazer.