← Concepts

Pourquoi c'est nécessaire

Une queue est une file de travail. Pour relancer une mission, Elora doit modifier l'item: nouvelle consigne, nouveau prompt de révision, retour en attente. Sans ledger, le passage done/failed -> pending peut rendre moins visible la tentative qui a échoué. L'Attempt Ledger sépare donc l'historique de l'exécution de l'état mutable de la queue.

brain@elora:~$ elora-execute revise EXECUTION_ID --apply --reason "livrable incomplet" --json
attempt: attempts/attempt-*.json
queue_snapshot: attempts/attempt-*.queue.json
revision: revisions/rev-*.md
queue: pending

brain@elora:~$ elora-execute attempts EXECUTION_ID --json
count: 1
latest: attempt-* | contract_violation

brain@elora:~$ elora-execute compare EXECUTION_ID --json
status: current_not_terminal | improved | regressed | unchanged

Après comparaison

Quand la tentative révisée est revenue en état terminal, elora-execute compare peut dire si le nouveau résultat s'est amélioré, a régressé ou n'a pas changé. Ensuite, elora-execute learn --apply peut écrire un item Revision Learning Bridge sous forme de proposition inspectable.

Ce qui est conservé

• l'identifiant de tentative et l'exécution liée;
• l'état terminal de queue;
• le snapshot complet de l'item queue avant mutation;
• le statut result_acceptance et les raisons de blocage;
• le result contract déterministe;
• les chemins des fichiers de résultat et d'artefacts;
• le lien vers la révision qui va relancer le travail.

Ce que le ledger ne fait pas

Il ne corrige pas le résultat, ne promeut pas automatiquement un apprentissage, ne modifie pas la mémoire canonique et ne change pas le routing. Il rend seulement la tentative inspectable, pour que l'opérateur ou les outils puissent comparer les essais successifs avec elora-execute compare puis, si utile, capturer une proposition learning explicite.