Checkpoints e Rollback

000". O fluxo de trabalho é confirmado, falha no meio da execução e é retomado. Se apenas a chave de idempotência for verificada e a execução for retomada, a transferência será executada uma vez (correto). Mas considere que, entre a falha e a retomada, o saldo de A caia para $500 por meio de um fluxo de trabalho diferente. A verificação de idempotência ainda passa; a pré-condição não. Sem uma verificação de pré-condição, realizamos uma transferência sem fundos (cheque especial).

Toda ação consequente precisa de ambos:

• Chave de idempotência: evita a execução dupla.
• Verificação de pré-condição: confirma se o estado ainda é consistente com o que foi aprovado.

Verificação pós-ação

"A ferramenta retornou 200" não é uma verificação. Uma verificação real lê novamente o estado de destino e confirma se o efeito colateral realmente aconteceu. Padrões:

• Atualização de banco de dados: UPDATE ... RETURNING * e então declarar (assert) que a linha retornada corresponde ao estado pretendido.
• Envio de e-mail: verificar a pasta de enviados para o ID da mensagem após o envio.
• Gravação de arquivo: ler o arquivo de volta e gerar seu hash.
• Chamada de API: fazer um GET subsequente no recurso de destino.

Se a verificação falhar, o fluxo de trabalho estará em um estado sabidamente ruim. O rollback é ativado.

Planos de rollback

Cada ação consequente em propor-depois-confirmar (Lição 15) carrega um plano de rollback. Tipos:

• Rollback in-band: reverte o efeito colateral diretamente (DELETE após INSERT, Send-correction-email após o envio).
• Transação de compensação: uma nova ação que neutraliza a original (padrão SAGA tradicional).
• Rollback out-of-band: alerta um humano, pausa o fluxo de trabalho, deixa o estado ruim para investigação.

O rollback no-op ("não podemos desfazer isso") deve ser nomeado na proposta. Ações sem rollback exigem um HITL mais forte no momento da confirmação (desafio e resposta da Lição 15).

Leitura operacional do Artigo 14 da Lei de IA da UE

O Artigo 14 exige "supervisão humana eficaz" para sistemas de alto risco. Em termos operacionais, os implementadores interpretam isso como:

• Os checkpoints são pesquisáveis por um auditor.
• Os rollbacks são ensaiados (testados de ponta a ponta pelo menos uma vez).
• A trilha de auditoria sobrevive a um deploy (o backend de checkpoint não é efêmero).
• As verificações que falham geram alertas, não sendo apenas registradas silenciosamente em logs.

Um fluxo de trabalho que falha no meio do commit, retoma e conclui o efeito colateral sem um caminho de verificação + rollback não passa no teste do Artigo 14.

O modo de falha crítico: a execução dupla

O incidente de produção mais comum neste espaço:

1. Ação aprovada, chave de idempotência k.
2. O commit começa, executa, retorna 200.
3. O fluxo de trabalho falha antes de persistir o status "confirmado" (committed).
4. O fluxo de trabalho é retomado; vê "aprovado, mas não confirmado"; executa novamente.
5. O efeito colateral ocorre duas vezes.

Mitigação: persista uma intenção "em andamento" (in-flight) antes da execução, execute com uma chave de idempotência e, em seguida, marque como "confirmado" somente após a verificação pós-ação ser bem-sucedida. Se a ação ocorrer e a gravação do status falhar, você saberá que deve verificar e (se necessário) disparar novamente. Se a gravação do status for bem-sucedida e a ação falhar, você verifica e dispara exatamente uma vez por meio do caminho de recuperação.

Use-o

code/main.py implementa um fluxo de trabalho com checkpoint, idempotência, pré-condições, verificação e rollback. O driver simula quatro cenários: execução limpa, nova tentativa após falha (a idempotência captura), falha de pré-condição (o fluxo de trabalho é abortado sem disparar) e falha de verificação (o rollback é ativado).

Envie-o

outputs/skill-rollback-rehearsal.md projeta um teste de ensaio de rollback para um fluxo de trabalho proposto e audita o backend de checkpoint para persistência da trilha de auditoria.

Exercícios

1. Execute code/main.py. Verifique os quatro cenários. Para o caso de falha durante o commit, confirme que a ação é disparada exatamente uma vez nas novas tentativas.

2. Modifique o padrão "marcar como concluído primeiro, depois fazer" para que a gravação do status ocorra após a ação. Execute novamente o cenário de falha. Meça quantas ações duplicadas são disparadas.

3. Projete um plano de rollback para uma ação de produção específica (por exemplo, "postar em um canal do Slack"). Classifique como in-band, de compensação ou out-of-band. Justifique a escolha.

4. Pegue um fluxo de trabalho que você conhece. Identifique cada transição de estado. Marque cada uma com um requisito de durabilidade (persistir / não persistir). Conte as que você não está persistindo atualmente.

5. Teste de rollback ensaiado: projeta um teste de ponta a ponta que executa um fluxo de trabalho real, simula uma falha nele e confirma que o caminho de rollback é ativado. O que o teste valida (assert)?

Termos-Chave

Termo	O que as pessoas dizem	O que realmente significa
Checkpoint	"Ponto de salvamento"	Cada transição de estado do grafo persiste em um armazenamento durável
Concessão (Lease)	"Reivindicação do worker"	Reivindicação de curta duração de que um worker está executando uma execução; expira em caso de falha
Pré-condição	"Portão de estado"	Asserção de que o estado ainda é consistente com a ação aprovada
Verificação pós-ação	"Verificação de releitura"	Confirma se o efeito colateral realmente aconteceu no sistema de destino
Rollback in-band	"Desfazer direto"	Reverte o efeito colateral com a operação inversa
Transação de compensação	"Desfazer SAGA"	Uma nova ação que neutraliza a original
Marcar como concluído primeiro	"Ordem de gravação de status"	Persiste o status de confirmado antes de retornar do commit
Artigo 14	"Supervisão humana da Lei de IA da UE"	Operacional: checkpoints pesquisáveis, rollbacks ensaiados, trilha auditável

Leituras Adicionais

• Microsoft Agent Framework — Checkpointing and HITL — primitivas de checkpoint e recuperação de concessão.
• Cloudflare Agents — Human in the loop — Durable Objects como um substrato de estado.
• EU AI Act — Article 14: Human oversight — linha de base regulatória.
• Anthropic — Measuring agent autonomy in practice — estrutura de confiabilidade para fluxos de trabalho de longo horizonte.
• Anthropic — Claude Code Agent SDK: agent loop — formato de fluxo de trabalho para Claude Code Routines.