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 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.