result_contract

Result Acceptance Gate

Un worker peut terminer sans produire un résultat utilisable. Le Result Acceptance Gate empêche Elora de confondre "la queue est done" avec "l'exécution est acceptée".

accepted

Le livrable est présent, utilisable, conforme au contrat disponible, et la clôture done est autorisée.

not_ready

La queue est encore pending/running, ou le résultat n'est pas synchronisé. Il faut sync/review avant de clôturer.

blocked states

failed, missing_artifacts, contract_violation et needs_revision bloquent close --outcome done sauf override explicite.

Ce que le gate inspecte

état queue et worker;
présence du résultat durable;
présence du livrable;
deliverable.usable, statut et raison;
statut du quality gate et fichiers quality.json / artefacts;
score et statut de review quand disponibles;
chemins vers result.md, result.json, quality.json et manifeste artefacts.

Harness déterministe

Le contrôle est maintenant matérialisé par elora-result. La commande valide un result contract sans modèle: présence de result.md, result.json, quality.json, artifacts/manifest.json, kinds de fichiers obligatoires, JSON lisible, statut usable et qualité non échouée.

brain@elora:~$ elora-result validate --queue-id QUEUE_ID --json
contract: elora.result.v1
status: passed | warning | failed
score: 0..100

sxqueue result --json expose aussi result_contract. elora-execute sync, review et close conservent le snapshot sous result_acceptance.evidence.result_contract, afin que le cockpit et l'audit voient exactement pourquoi un résultat est accepté, bloqué ou en révision.

Vérification des affirmations

Quand un livrable expose un result.md, le gate peut aussi conserver un snapshot Claim Verification Gate. elora-verify extrait les claims, prépare des questions ouvertes, vérifie seulement des preuves indépendantes fournies, puis classe les affirmations en keep, revise_or_mark_uncertain, remove_or_revise ou mark_uncertain.

En V1, une affirmation sans preuve devient un warning unverifiable. Elle ne bloque pas automatiquement une exécution interne, mais elle doit être traitée avant usage public, externe ou critique. Une contradiction explicite contre les preuves fournies bloque l'acceptation.

Boucle de reprise

Quand le gate bloque, elora-execute redo appelle d'abord Result Quality Arbitration, décide si une reprise est requise et autorisée, puis transforme les raisons en demande de correction explicite. La commande écrit un nouveau prompt de révision via la primitive revise, attache le snapshot au record d'exécution, puis remet la queue en pending sans mutation mémoire ni changement de routing. Le détail est décrit dans la page Redo / Revision Loop.

Frontière dure

elora-execute sync et elora-execute review rafraîchissent result_acceptance dans le record d'exécution. elora-execute close --outcome done --apply lit ce snapshot et refuse une exécution dispatchée qui n'est pas acceptée.

Le feedback résultat est séparé de cette frontière. Un feedback accepted signifie que Christophe juge le résultat utile comme signal learning; il ne donne pas à lui seul le droit de fermer l'exécution comme faite.

L'opérateur peut forcer uniquement avec --allow-unaccepted-result --override-reason "...". La raison est stockée dans .close.result_acceptance_override et auditée. L'override ne rend pas le résultat meilleur; il documente seulement une décision opérateur.

Cas manuel

Une exécution sans queue worker n'est pas soumise au même gate. Elle reçoit le statut manual_not_applicable: la clôture reste possible, mais la note opérateur doit expliquer ce qui a réellement été fait.