revision_learning

Revision Learning Bridge

Une révision utile ne doit pas seulement produire un meilleur résultat. Elle doit aussi laisser un signal exploitable pour comprendre ce qui a échoué, ce qui a corrigé, et ce qu'il faudra améliorer plus tard.

Comparaison

elora-execute compare lit l'Attempt Ledger et le résultat courant pour détecter improved, regressed ou unchanged.

Capture

elora-execute learn --apply écrit un item execution_revision_comparison quand la comparaison est prête.

Revue

L'item apparaît dans le Learning Review Inbox. Il attend une décision opérateur, pas une mutation automatique.

Pipeline

failed result
  -> revision request
  -> attempt snapshot
  -> queue rerun
  -> sync terminal result
  -> compare attempt/current
  -> learn --apply
  -> execution_revision_comparison.jsonl
  -> learning inbox review

Ce que cela permet

Elora peut maintenant conserver un lien propre entre un échec, une correction et le résultat obtenu après correction. Si une révision améliore le score du result contract, réduit les raisons de blocage ou transforme un résultat non accepté en résultat accepté, ce signal devient consultable dans les index learning.

Ce signal est utile pour repérer les patterns: prompts de révision efficaces, agents qui régressent, quality gates trop faibles, livrables récurrents incomplets, playbooks à durcir.

Ce que cela interdit

Le bridge ne promeut rien tout seul. Il n'écrit pas la mémoire canonique, ne modifie pas le routing, ne change pas les providers, ne corrige pas les contrats agents et ne remplace pas la décision opérateur. Il produit une preuve de plus pour la boucle de revue.

Invariant: apprendre d'une correction ne signifie pas s'auto-modifier. Le système propose, l'opérateur valide, puis une promotion explicite peut exister.