Juillet 2026

Juillet commence par un changement de statut: le coeur opératoire V1 d'Elora n'est plus seulement une accumulation de couches. Un premier gate de clôture a été exécuté de bout en bout et donne un verdict ready_with_known_limits.

Verdict V1

Le verdict ne signifie pas qu'Elora est finie, ni que chaque agent est excellent, ni que chaque surface est parfaite. Il signifie que le chemin local cockpit/CLI est utilisable pour des missions réelles: objectif, plan, dispatch, worker local, sync, review, acceptance, synthèse, livraison finale, feedback, outcome, learning proposal-only et clôture.

Preuve de chemin

• 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

Le pack a révélé une friction utile: une demande Hello World avec la contrainte "sans modifier le repo" partait en analyse OpenCode read_only au lieu d'utiliser le worker natif déterministe. Le routage a été corrigé: produire un artefact Hello World sélectionne maintenant le backend native, écrit seulement dans la session worker, valide avec bash -n, exécute localement et garde repo_edited=false.

Field trial cockpit

Le 4 juillet, un nouveau pack terrain a relancé cinq scénarios génériques via elora-live-run: analyse de site fourni, analyse documentaire, proposition de mise à jour documentaire, forecast local et artefact code local. Les cinq scénarios finissent safe, accepted, delivered et done, sans Telegram, Hermes, Codex, provider distant ou écriture en mémoire canonique.

Une correction sémantique a aussi été faite: les phases lentes restent visibles dans operator_friction, mais ne transforment plus seules une mission réussie en warning. Un warning doit signaler une incertitude ou un risque de résultat, pas seulement une latence.

Correction du go web research

Un test cockpit réel a montré un échec différent d'un problème UI: après confirmation go d'une recherche web, le bridge d'exécution ne démarrait pas proprement, puis créait une queue legacy sans lifecycle. La cause était un décalage entre le plan conversationnel web_facts/current_web_facts et le re-routing indépendant de elora-execute mission.

La correction ajoute le playbook borné web_research_brief. Les recherches web générales et current facts confirmées par go conservent maintenant le cycle complet: bridge d'exécution, dispatch vers strategic_research_agent, queue worker, supervision preview, sources, limites de fraîcheur et inconnues explicites. Le fallback legacy reste possible seulement si le bridge échoue réellement.

Style cockpit opérateur

Le cockpit local a reçu une passe visuelle cohérente avec l'univers StackX monitoring: noir profond, panneaux durs, lignes vertes, densité plus forte, moins d'effets glossy. Le changement reste strictement présentationnel: le navigateur continue d'appeler les contrats CLI/API Elora et ne possède ni mémoire, ni routing, ni policy, ni provider.

Limites connues

• Les warnings de claim verification et les inconnues de contexte restent visibles. Ils ne doivent pas être maquillés par la couche de livraison.
• 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. La bonne stratégie est d'utiliser Elora sur de vraies missions, de corriger les frictions concrètes observées, et de n'ajouter une capacité que lorsqu'un contrat existant ne couvre pas le travail proprement.