Verifique reivindicações de "feito" contra a verdade fundamental, não a palavra do agente

Visão Geral

Quando um agente de IA diz "feito", "enviado" ou "corrigido", isso é uma reivindicação, não um fato — e uma reivindicação que o agente verifica relendo seu próprio trabalho é consistência, não fundamentação. Esta habilidade substitui esse auto-relato por um veredito de uma testemunha que o agente não escreveu: ela usa o kernel do DOS (dos verify, dos commit-audit) para confirmar o efeito reivindicado a partir da ancestralidade do git e do diff real do commit. O DOS é determinístico — sem chave de API, sem LLM. O veredito é apenas git e offline como usado aqui; a única exceção é dos verify em um espaço de trabalho que conecta um oráculo de CI, que --no-ci suprime (veja Notas de Segurança e Proteção).

Esta habilidade adapta o padrão de "reivindicação-testemunha" de referência do DOS (anthony-chaudhary/dos-kernel) em um roteiro agnóstico ao host.

Quando Usar Esta Habilidade

• Use quando um agente relata uma tarefa/fase/funcionalidade como completa e você deseja que esse "feito" seja confirmado por evidências antes de construir sobre ele.
• Use logo após um commit, para confirmar que a mensagem do commit corresponde ao seu diff (capturar um fix: que apenas tocou um README, ou um "testes passam" que excluiu as asserções).
• Use ao juntar resultados de muitos sub-agentes — verifique cada efeito reivindicado em vez de confiar na string de retorno.
• Não o use para julgar se o código está correto — para isso serve o conjunto de testes. Esta habilidade verifica se a coisa reivindicada realmente foi enviada.

Como Funciona

Passo 1: Instale o kernel (uma vez)

python3 -m venv .dos-venv
. .dos-venv/bin/activate
python -m pip install 'dos-kernel==<reviewed-version>'  # provides the `dos` CLI

Passo 2: Audite a reivindicação do último commit vs seu diff

O assunto de um commit pode ser forjado (quem escreveu a mensagem a escreveu); os arquivos que ele tocou, não (o git o fez). dos commit-audit avalia o assunto contra o diff real:

dos commit-audit --workspace . HEAD --json

commit-audit --json imprime um array JSON de commits auditados (um elemento mesmo para um único HEAD), então leia verdict do primeiro elemento — por exemplo, dos commit-audit --workspace . HEAD --json | jq -r '.[0].verdict'. (Sem --json, o mesmo veredito é impresso como uma linha de texto única: · OK …, ⚑ UNWITNESSED …, ou · abstain ….) Os vereditos são: OK (o diff suporta o tipo da reivindicação), CLAIM_UNWITNESSED (a reivindicação do assunto não é evidenciada pelo diff — trate o "feito" como não provado), ou ABSTAIN. Isso julga o tipo de mudança, nunca a correção — execute os testes para isso.

Passo 3: Verifique se uma fase nomeada realmente foi enviada

Se o agente reivindicar que um plano/fase específico foi concluído, confirme-o a partir do histórico do git em vez da transcrição:

dos verify --workspace . PLAN PHASE --json --no-ci

--no-ci mantém o veredito apenas no git (veja a nota de Segurança abaixo). Com --json, você obtém os campos shipped e source. (A forma de texto padrão imprime SHIPPED PLAN PHASE (via grep) ou NOT_SHIPPED PLAN PHASE (via none) — o mesmo veredito, e o código de saída do processo é não-zero quando não enviado.)

Avalie shipped: true pelo source, porque o fallback do git se avalia pela forjabilidade — e evidências forjáveis são exatamente o que esta habilidade existe para desconfiar:

• registry ou grep-artifact — não forjável (uma linha de registro, ou um artefato/diff registrado). Isso fecha a reivindicação.
• grep-subject (ou apenas grep) — forjável: um assunto ou corpo de commit carregou o token da fase, que um agente pode escrever sem fazer o trabalho (mesmo em um commit vazio). Trate isso como enviado-conforme-o-assunto, não confirmado — corrobore-o (execute dos commit-audit nesse commit, abaixo) antes de fechar.
• none — nenhuma evidência positiva; aceite como "não enviado", não como uma falha da ferramenta.

Passo 4: Junte apenas efeitos confirmados

Aceite o "feito" do agente apenas quando o Passo 2/3 o corroborar. Se CLAIM_UNWITNESSED ou shipped: false, o trabalho não está feito, independentemente de quão confiantemente o agente o narrou — envie-o de volta.

Exemplos

Exemplo 1: Gate uma reivindicação de "Eu corrigi o bug" de um agente

# The agent committed and said it's fixed. Check the diff backs the claim.
# commit-audit --json returns an array, so read the first element's verdict:
dos commit-audit --workspace . HEAD --json | jq -r '.[0].verdict'
# OK                -> the change is of the claimed kind; now run the tests
# CLAIM_UNWITNESSED -> the commit doesn't do what it says; reject

Exemplo 2: Confirme o envio de uma fase de funcionalidade antes de fechar um ticket

…