Notes courtes, sans théâtralité inutile. Le journal documente ce qui change dans Elora et pourquoi.
Premier verdict V1: ready_with_known_limits
Le V1 Closure Gate donne un premier verdict command-backed: ready_with_known_limits. Une mission fraîche sur https://elora.systems a traversé le chemin opérateur complet: mission, dispatch, worker local déterministe, sync, review, acceptance, synthèse, livraison finale, feedback explicite, outcome, learning proposal-only et clôture done. Un pack de simulation opérateur a ensuite validé cinq scénarios elora-live-run via cockpit isolé, dont code local natif, sans Telegram, Hermes, Codex ni provider distant. Le field trial du 4 juillet confirme ces cinq chemins en safe, accepted, delivered et done; les lenteurs restent en operator_friction, séparées du statut de sûreté. Le même jour, le flux go des recherches web/current facts a été corrigé: il force désormais web_research_brief, garde le bridge d'exécution et la supervision, et ne tombe plus dans une queue legacy sans lifecycle. Le cockpit adopte aussi une direction visuelle plus StackX monitoring: noir, vert, dense, local, sans transfert d'autorité au navigateur. Les limites restent visibles: warnings de claim verification, inconnues explicites, mémoire à remplir, agents à spécialiser plus finement, Telegram secondaire et modèles locaux additionnels.
Formalisation publique du projet, séparation de l'identité Elora et des workers, première structure du cockpit local, routage Hermes/Codex, queue, résultats et contrôle des surfaces.
Golden Paths certifiés, dialogue mission, operator loop
Sept missions standard sont maintenant certifiées localement par elora-trial avec execution_proven=true. Elora expose aussi un plan de mission conversationnel: objectif, route, agent, livrables et gates avant tout lancement, puis confirmation go pour passer dans la queue. Après ce go, le chat peut répondre à ou ca en est ? ou prochaine action avec un statut read-only fondé sur elora-execute completion et next-action. Le cockpit affiche maintenant les actions naturelles du plan pending et du post-go comme raccourcis de surface: lancer, ajuster, annuler, statut, continuer, synthèse ou livraison repassent toujours par elora-chat, sans autorité navigateur. Les pending missions obsolètes disposent aussi d'une sortie explicite: pending-cancel marque le brouillon cancelled avec raison opérateur, conserve l'historique et le retire du focus actif; le Workbench les range ensuite dans une Mission Inbox filtrable, en historique inspectable séparé du travail actif. Le programme V1 restant est désormais cadré autour du coeur opératoire générique; elora-execute operator-loop ajoute le contrat quotidien "quoi faire maintenant", Result Quality Arbitration ajoute le gate qualité safe/warning/blocked/not_ready, et Provider Runtime Binding rend le lien entre providers locaux et runtimes inspectable sans rendre Ollama obligatoire. Les pipelines métier restent des capacités détachables, pas le centre de l'architecture.