← Concepts

Pourquoi ce n'est pas un simple retry

Un retry brut peut reproduire la même erreur, surtout si le prompt initial n'explique pas le défaut observé. Le redo ajoute une couche Elora: il lit l'arbitrage qualité, extrait les causes de blocage, formalise les corrections attendues et rebranche le worker avec ce contexte. La primitive revise reste disponible en dessous, mais le chemin opérateur normal passe par redo.

brain@elora:~$ elora-execute redo EXECUTION_ID --dry-run --json
status: preview
redo_required: true
redo_allowed: true
queue_action: retry | requeue
acceptance: contract_violation | failed | needs_revision

brain@elora:~$ elora-execute redo EXECUTION_ID --apply --reason "corriger le livrable incomplet" --json
status: revision_requested
attempt: attempts/attempt-*.json
queue: pending
prompt: revisions/rev-*.md

Ce qui est stocké

• un Attempt Ledger local avant mutation de la queue;
• le snapshot complet de l'item queue terminal sous attempts/attempt-*.queue.json;
• le snapshot result_acceptance qui a bloqué;
• le snapshot du redo gate: redo_required, redo_allowed, blockers, warnings et plan de reprise;
• les raisons de reprise/révision et corrections requises;
• le chemin du prompt original et du prompt révisé;
• la transition queue done/failed -> pending;
• l'historique revision_loop.history dans l'exécution et la queue;
• la raison opérateur quand la révision est appliquée.

Limites V1

La boucle ne corrige pas automatiquement un livrable et ne promeut aucun apprentissage. Elle prépare une nouvelle tentative mieux cadrée. Un résultat déjà accepté n'est pas repris par défaut; il faut un --force explicite. La capture learning reste une étape séparée: l'échec peut ensuite alimenter des propositions de playbook, de route ou de contrat agent, mais pas muter le système en silence.