Juillet 2026

Juillet 2026 marque le passage du coeur cockpit/CLI d'Elora vers un état utilisable en conditions réelles, avec un premier verdict ready_with_known_limits. Le système reste en construction, mais le chemin opérateur local est maintenant prouvé: objectif, plan, dispatch, worker local, sync, review, acceptance, synthèse, livraison finale, feedback, outcome, learning proposal-only et clôture.

Jalons

• V1 Closure Gate: premier verdict ready_with_known_limits pour le coeur opératoire local. Le verdict ne prétend pas qu'Elora est finie; il confirme qu'un chemin utile cockpit/CLI existe et reste inspectable.
• Une ancienne exécution de mai a été clôturée comme blocked parce qu'elle précédait le contrat external_context_boundary. Elle n'a pas été réparée artificiellement.
• Une mission fraîche sur https://elora.systems a été lancée via elora-execute mission, dispatchée vers un worker local déterministe, synchronisée, revue, synthétisée, livrée, annotée par feedback, passée en outcome, capturée en learning proposal-only et clôturée done.
• Un pack de simulation opérateur a ensuite traversé cinq scénarios elora-live-run via cockpit loopback isolé: analyse de site, analyse documentaire, mise à jour documentaire, forecast local et code local. Les cinq chemins finissent acceptés, livrés et clôturés sans Telegram, Hermes, Codex ni provider distant.
• Le point important est le chemin, pas la beauté du livrable de test: un worker terminé ne suffit pas; Elora doit passer par acceptance, synthèse, livraison, feedback et clôture auditable.
• Correction local_code: les demandes d'artefact simple avec contrainte "sans modifier le repo" sélectionnent le backend natif déterministe, écrivent seulement dans la session worker, valident avec bash -n, exécutent localement et gardent repo_edited=false.
• Field trial cockpit du 4 juillet: cinq scénarios génériques ont été relancés via elora-live-run et finissent safe, accepted, delivered et done, sans Telegram, Hermes, Codex, provider distant ou écriture en mémoire canonique.
• Field trial cockpit du 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.
• Correction readiness: un timeout intermittent du doctor elora-evidence en mode core-v1 --fast reste maintenant un warning visible, pas un faux blocker du coeur V1. Les vrais échecs de board, loop, evidence JSON, verification, E2E ou trial inventory restent bloquants.
• Pack lancement/reprise V1: elora-operate status donne maintenant une réponse unique à "puis-je utiliser Elora maintenant ?". Il agrège readiness V1, cockpit, queue, reprise running en dry-run, board d'exécution, runtime local et ledger opérateur, puis sépare next_action immédiate et recovery_actions pour la dette historique. Le contrat est lecture seule: pas de worker caché, pas de mutation queue, mémoire, routing, provider ou policy, pas de dépendance systemd, pas de dépendance Telegram.
• Correction sémantique des warnings: les phases lentes restent visibles dans operator_friction, mais ne transforment plus seules une mission réussie en warning de sûreté.
• Correction du go web research: les recherches web/current facts confirmées conservent maintenant le bridge d'exécution, le playbook borné web_research_brief, la queue worker, la supervision preview, les sources, les limites de fraîcheur et les inconnues explicites.
• Continuation ciblée des workers: Elora distingue run_queue_once pour une queue pending et sync_queue pour un worker déjà running. Le cockpit expose Lancer worker cible sans consommer un autre job global.
• Continuation cockpit one-click: Continuer mission lit maintenant elora-execute next-action puis applique uniquement l'action bornée courante quand elle est whitelistee: worker ciblé attaché, runtime local, sync, review ou safe continuation. Les confirmations exactes restent pour les actions sensibles ou directes; le chemin quotidien ne demande plus un mot magique inutile.
• Gate runtime local: un worker Hermes branché sur Ollama vérifie maintenant le runtime avant lancement. Si Ollama est arrêté, l'exécution passe en worker_runtime_blocked et propose start_local_runtime sans consommer la queue.
• elora-runtime porte le contrat readiness/ensure générique, tandis que elora-models select expose tâche, provider, runtime et modèle sans inférence ni mutation.
• Préparation des runtimes locaux vLLM et llama.cpp: elora-runtime install local_vllm installe vLLM dans un venv repo-local, et elora-runtime install local_llama_cpp --gpu auto construit llama-server. Les deux chemins restent server-only: aucun poids téléchargé, aucun modèle lancé, aucune mutation provider/routing/mémoire.
• Workbench dégradé plutôt que cassé: le cockpit ne transforme plus l'échec d'un endpoint read-only en erreur globale; il charge ce qui reste disponible et affiche l'endpoint fautif.
• Style cockpit opérateur: passe visuelle cohérente avec l'univers StackX monitoring, sans transfert d'autorité au navigateur.
• Les warnings de claim verification et les inconnues de contexte restent visibles. Ils ne doivent pas être maquillés par la couche de livraison.
• Audit de fermeture V1 du 10 juillet: la compréhension naturelle distingue maintenant une lecture documentaire d'une demande de modification, les missions conversationnelles peuvent aller jusqu'à la livraison finale, et la réponse opérateur ne déverse plus la queue, les gates et tous les chemins d'audit dans le dialogue.
• Operator Judgment Contract du 11 juillet: lorsqu'une mission s'arrête pour une vraie décision, Elora expose maintenant la question, les constats déterministes, sa recommandation et les choix possibles. Un livrable refusé par les quality gates ne produit plus un vague « j'ai besoin de ton jugement »: le cockpit montre les défauts et propose une reprise bornée en un clic, sans acceptation, clôture, learning ou mutation mémoire/routing/provider implicite.
• Revision Cycle Closure du 12 juillet: une reprise ne peut plus réutiliser la review d'un ancien worker ni imbriquer récursivement les prompts de correction. La source canonique reste récupérable dans les historiques legacy déjà pollués, un apply dupliqué est idempotent et le bouton cockpit reste occupé pendant l'action. Chaque nouveau run_id est synchronisé puis revu, les contrôles qualité échoués sont transmis au worker, et le cockpit remplace l'ancien choix par la tentative, l'évolution du score et le nouvel arbitrage. Après plusieurs échecs sans progrès, l'inspection est recommandée avant une nouvelle relance.
• Bounded Quality Convergence du 12 juillet: après un go et une continuation explicite, Elora ne redemande plus un clic pour chaque échec qualité. safe-continue peut enchaîner redo audité, même queue, nouveau worker run_id, sync et review jusqu'à acceptation, stagnation ou plafond total de trois révisions. Les critères ne sont jamais abaissés; feedback, acceptation, clôture, learning, mémoire, routing et providers restent hors de la boucle automatique.
• Intégrité session/exécution du 12 juillet: les exécutions issues du dialogue conservent maintenant leur session_id. Le Workbench suit l'exécution du transcript avec loop --focus, affiche le scope actif et bloque toute action visant une mission globale différente. Une conversation et son inspecteur ne peuvent plus montrer deux exécutions incompatibles après refresh.
• Fermeture de course asynchrone du 14 juillet: les chargements de session et de Workbench portent maintenant une génération monotone. Sélectionner une conversation invalide immédiatement les réponses globales ou précédentes encore en vol, purge les sélections d'exécution et de résultat, recharge le transcript persistant puis son scope d'exécution. Les retours tardifs d'une action Workbench sont eux aussi ignorés hors de leur session. Un ancien blocker ne peut plus écraser l'inspecteur actif après un changement rapide ou la fin d'un tour.
• La synthèse finale est désormais evidence-first: artefact métier principal sélectionné déterministiquement, rendu sémantique optionnel par provider local avec provenance explicite, fallback extractif si le modèle est indisponible, et audit complet conservé séparément.
• La readiness distingue maintenant le socle déterministe du langage sémantique: si aucun provider modèle n'est prêt, le cockpit et les workers command-backed peuvent rester utilisables en mode warning, mais Elora ne prétend plus disposer d'un dialogue naturel ou d'un rendu model-backed pleinement opérationnel.
• Hermes a été vérifié et mis à jour vers v0.18.2. Il reste un overlay optionnel; les corrections upstream de contrats de résultats, provenance, attribution d'usage et isolation de profils renforcent ses missions sans en faire le coeur d'Elora. Sa compression reste branchée sur le modèle local principal, son navigateur et son scanner de commandes local sont vérifiés, son curator automatique est en pause et chaque sortie modèle est bornée pour qu'un tour défectueux ne monopolise pas un worker.
• Research Runtime Capability Closure du 13 juillet: Elora distingue désormais recherche dans un corpus local, inspection d'une URL fournie et découverte Internet ouverte. web_research_brief bloque avant dispatch si aucun SearXNG/YaCy ou spécialiste connecté n'est réellement prêt. Un worker qui termine sans trace d'outil, source ou artefact exploitable devient runtime_incompatible; les reprises automatiques et manuelles s'arrêtent jusqu'à un changement de runtime ou l'ajout d'URLs. Le cockpit affiche le capability doctor et des remèdes concrets au lieu de répéter le même run Hermes.
• Web Research Bridge Closure du 14 juillet: la preview, l'apply et le chat partagent désormais la même décision de readiness. Une découverte Internet indisponible bloque avant création d'ancres opérateur, d'exécution, de worker ou de queue. Le bridge ne transforme plus ce refus en fallback Hermes; le plan reste en attente et peut reprendre naturellement dès qu'une URL est fournie ou qu'un moteur SearXNG/YaCy devient prêt.
• Managed Public Search Runtime du 15 juillet: Elora sait maintenant installer, mettre à jour, démarrer, arrêter, sonder et maintenir un SearXNG loopback sans systemd. Les recherches ouvertes passent par strategic_research_agent -> local_research, avec recherche, fetch borné, qualification des sources, notes, fact-check, inconnues, synthèse evidence-first et result contract. Les plans anciens sont reroutés au go; Hermes et le rendu modèle restent optionnels, et un échec de bridge ne recrée plus de queue legacy.
• Semantic Research Quality Loop du 15 juillet: le worker de recherche ne remet plus directement un brouillon structurel à Christophe. Il part d'une synthèse déterministe liée aux preuves, la soumet à un critique sémantique local, applique au plus deux reprises et rejoue les gates déterministes. Le cockpit expose semantic_quality, le score, les tentatives, les reprises et le fallback dégradé; une première version acceptée sans reprise reste bien une version contrôlée.
• GLM Local Reasoning/Code Runtime du 21 juillet: l'artefact officiel Ollama glm-4.7-flash:q4_k_m (30B-A3B MoE, environ 19 Go en Q4_K_M) est installé, sondé et validé par une inférence OpenAI-compatible locale. Il devient le spécialiste pratique de local_reasoning et local_code_model; SuperGemma reste le modèle conversationnel primaire. GLM-5.2 et ses 753B paramètres restent réservés à un futur runtime frontier adapté. Les écritures, commandes, tests, diffs et acceptations restent gouvernés par les workers et gates Elora, pas par le modèle.
• La fermeture a été validée par une régression intégrale propre de 1 h 04 min 50 s: 19 blocs, missions E2E, 21 trials, cockpit, providers, workers, gates, apprentissage proposal-only, handoff et rendu final local. Le doctor profond du harness traite désormais ses rapports volumineux sans faux succès, et un daemon long-running sain mais arrêté reste un avertissement optionnel plutôt qu'un blocage du cockpit/CLI.
• Le feedback de clôture du trial valide le chemin opératoire, pas un niveau éditorial final pour chaque analyse produite.
• La mémoire doit encore être remplie et curée; les agents doivent continuer à gagner en spécialisation; Telegram reste une surface secondaire; les modèles locaux additionnels restent des accélérateurs remplaçables.
• Conséquence: la prochaine étape par défaut n'est plus d'ajouter une nouvelle couche, mais d'utiliser Elora sur de vraies missions, corriger les frictions observées et n'ajouter une capacité que lorsqu'un contrat existant ne couvre pas le travail proprement.