← Concepts

revision_loop

Revision Loop

Un résultat bloqué ne doit pas devenir une interprétation manuelle floue. Elora transforme l'échec en demande de révision explicite, inspectable et transmise au worker suivant.

Demande explicite

elora-execute revise génère une demande de correction avec raisons, actions requises, evidence, prompt original et raison opérateur.

Requeue utile

La queue repasse en pending avec un nouveau prompt de révision. Le worker ne relit pas seulement la même demande: il reçoit pourquoi la précédente sortie a échoué.

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é. La boucle de révision ajoute une couche Elora: elle lit le résultat, extrait les causes de blocage, formalise les corrections attendues et rebranche le worker avec ce contexte.

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

brain@elora:~$ elora-execute revise 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é

Limites V1

La boucle ne corrige pas automatiquement un livrable et ne promeut aucun apprentissage. Elle prépare une nouvelle tentative mieux cadrée. 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.

Invariant: la révision est un chemin de correction, pas une excuse pour accepter du médiocre. Si le résultat est mauvais, Elora le dit, le documente, et demande une sortie conforme au contrat.