Signal dur
Le point de départ est local et déterministe: worker failed, result contract invalide, review faible, artefacts absents ou Result Acceptance Gate bloqué.
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.
Le point de départ est local et déterministe: worker failed, result contract invalide, review faible, artefacts absents ou Result Acceptance Gate bloqué.
elora-execute revise génère une demande de correction avec raisons, actions requises, evidence, prompt original et raison opérateur.
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é.
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
attempts/attempt-*.queue.json;result_acceptance qui a bloqué;done/failed -> pending;revision_loop.history dans l'exécution et la queue;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.