Notes courtes, sans théâtralité inutile. Le journal documente ce qui change dans Elora et pourquoi.
Du dialogue naturel à une mission réellement livrée
Le coeur conversationnel ne laisse plus un ancien contexte enfermer Christophe dans une boucle. Une mission claire produit maintenant un plan, puis un seul go peut lancer le worker ciblé et faire avancer les étapes sûres jusqu'au livrable ou à un véritable arbitrage. Une mission publique sur Bash 5.3 a validé ce chemin en isolation: recherche locale, artefacts sourcés, contrôle, synthèse et livraison finale. La migration vers le Spark/GB10 dédié suit une politique native-first: PostgreSQL 17 + pgvector privé et passerelle cockpit Caddy en HTTPS avec mot de passe navigateur par défaut, mTLS optionnel, sans Docker ni systemd, tandis que le coeur reste exclusivement sur la loopback.
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 8 juillet, le pack complet existant elora-live-run run-all passe 6/6 scénarios en isolation locale: analyse de site, scénario StackX détachable, analyse documentaire, mise à jour documentaire, forecast local et code local Hello World. Les six atteignent safe, accepted, delivered, feedback enregistré, learning proposal-only capturé et clôture done. Un timeout intermittent du doctor elora-evidence en mode core-v1 --fast reste maintenant un warning visible au lieu d'un faux blocker du coeur V1. elora-operate status ajoute le pack lancement/reprise V1: une réponse unique, lecture seule, pour savoir si Elora est utilisable maintenant, quelle action ouvrir et quelle dette historique inspecter. 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. Depuis le 14 juillet, une readiness, une policy, une route ou un input bloquant ne peut plus être contourné par une queue Hermes legacy: le refus reste structuré, aucun worker n'est créé et le même plan peut reprendre après ajout d'une URL ou activation de la capacité requise. Le cycle post-go distingue aussi run_queue_once pour une queue pending et sync_queue pour un worker running, afin de lancer seulement le worker ciblé par l'exécution. Si ce worker dépend d'Ollama et que le runtime local est arrêté, Elora bloque maintenant en worker_runtime_blocked et propose start_local_runtime sans consommer la queue. Le contrat elora-runtime porte désormais la readiness/ensure/install générique: Ollama reste ergonomique, vLLM sert le haut débit local, et llama.cpp sert le chemin GGUF contrôlable. elora-models select expose tâche, provider, runtime et modèle sans inférence. Le Workbench charge aussi en mode dégradé quand un endpoint read-only échoue, au lieu de masquer toute la surface derrière un 502 global. Il suit désormais l'exécution liée à la session active avec loop --focus, au lieu d'afficher une mission globale différente après refresh. Les lectures asynchrones portent maintenant une génération de scope: changer de conversation invalide toute réponse globale ou précédente encore en vol, purge les sélections d'exécution et ignore les retours d'action hors scope avant de recharger le transcript et son exécution. 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.