Juin 2026

Juin démarre par le passage des Golden Path Missions de l'état simplement mappé à l'état prouvé localement. Le point important n'est pas cosmétique: Elora distingue désormais ce qu'elle sait cadrer, ce qu'elle sait vérifier en readiness-only, et ce qu'elle a réellement exécuté en full E2E local.

Jalons

• Golden Path Certification Run 2026-06-01: elora-execute certify-golden-paths --apply --include-e2e --ready-paths-only --json a certifié sept chemins prêts: analyse de site, prospection StackX, analyse documentaire, mise à jour documentation, code local, forecast séries temporelles et support ticket triage. Chaque chemin possède un run elora-trial full E2E passed avec execution_proven=true.
• Support Ticket Triage Worker Bridge V1: support_ticket_triage passe de gap actionnable à chemin certifié grâce à local_support_worker / ./bin/elora-support. Le worker lit seulement des preuves fournies, produit classification, gaps, next actions et brouillon client avec disclosure IA, sans envoyer de message ni muter un ticket.
• Cockpit Support Triage Integration V1: le cockpit expose maintenant une console Support dédiée via POST /api/support/triage. Christophe peut coller un ticket, un contexte et une procédure éventuelle; le cockpit appelle le worker local, affiche le rapport, la qualité et le brouillon IA, mais ne contacte personne, ne mute aucun ticket et n'écrit pas la mémoire.
• Cockpit Worker Registry / Capability Launcher V1: le cockpit expose /api/workers, /api/worker et /api/worker/run. Les workers locaux queue-compatibles elora-site, elora-docs, elora-code, elora-forecast, elora-prospect et elora-support deviennent lançables depuis une console commune. elora-scrapegraph est listé comme capacité directe, mais reste hors launcher générique V1. Le cockpit affiche readiness, policy, résultat, qualité et artefacts sans posséder l'autorité.
• Worker Execution Lifecycle V2: chaque run direct du Worker Registry conserve désormais un lifecycle local avec preflight gate, result contract, quality gate, learning hint, fichiers d'audit et feedback opérateur proposal-only. Le cockpit peut relire /api/worker/lifecycle et enregistrer un feedback uniquement avec confirmation APPLY WORKER FEEDBACK, sans mémoire canonique, sans routing mutation et sans promotion automatique.
• Worker Result Contract Normalization V1: les workers directs écrivent désormais un result.json normalisé avec payload natif conservé, native_result, deliverable validable par elora-result, result.md, quality.json, manifest et snapshots natifs sous artifacts/. Un run direct peut donc être affiché safe seulement si le contrat de résultat passe réellement.
• Worker-to-Mission Bridge V1: un run direct lancé depuis le Worker Registry peut maintenant être attaché au lifecycle elora-execute via attach-worker ou /api/worker/attach. L'exécution direct_worker conserve le lifecycle, le résultat normalisé, le Result Acceptance Gate et la prochaine action sûre, puis peut passer par synthèse, livraison, feedback, outcome et fermeture sans relancer le worker ni muter mémoire/routing/provider.
• V0 Operational Acceleration: après ATTACH WORKER, le cockpit charge maintenant l'exécution direct_worker créée et expose les raccourcis de suite, sans contourner les gates elora-execute. La Readiness Matrix expose aussi cockpit_direct_status pour distinguer un daemon arrêté d'un chemin local cockpit/CLI encore utilisable. Les sources readiness sont parallélisées et bornées par timeout pour éviter qu'un doctor lent gèle l'interface.
• Cockpit Direct Ready V1: elora-agent doctor --fast, elora-playbook doctor --fast et elora-harness doctor --fast donnent une lecture rapide du chemin cockpit sans lancer les audits profonds. elora-readiness matrix expose maintenant source_timings, slow_sources et cockpit_direct.advisory_warnings. Les warnings optionnels ne bloquent plus le chemin direct quand les contrats locaux sont prêts; un registre Markdown absent reste optionnel tant qu'aucune mission ne fournit de context file. elora-readiness cockpit-direct-smoke --json vérifie le chemin pratique avec fast doctors, mission dry-run, board et loop, sans worker ni mutation.
• V1 Core Readiness Gate: elora-readiness core-v1 --json agrège Readiness Matrix, Cockpit Direct Smoke et Mission V0 Acceptance en un verdict opérateur ready, warning ou blocked. Le cockpit l'expose via /api/readiness/core-v1 et un bouton explicite Verifier V1 Core. Ce bouton utilise désormais core-v1 --fast, elora-acceptance doctor, des fast doctors et des timeouts bornés; il expose cockpit_cli_core_status, release_validation_mode et long_running_control_plane_status. La validation release complète reste elora-readiness core-v1 --json sans --fast ou elora-acceptance check --json. Aucun modèle, worker dispatch, mémoire canonique, mutation routing/provider/policy ou autorité navigateur.
• Operator Start / Mission Launch V1: le Workbench devient le point d'entrée quotidien. Il commence par Etat operationnel Elora avec readiness légère, dernier verdict V1 Core connu, cockpit direct, operational core, focus et prochaine action sûre. Le gate V1 Core complet reste déclenché explicitement par Verifier V1 Core, tandis que Mission libre est maintenant disponible directement dans Workbench pour preview/start/dispatch via elora-execute mission sans transférer l'autorité au navigateur.
• Action principale Workbench V1: le Workbench affiche maintenant une action primaire dans son premier niveau opérateur. Elle choisit uniquement parmi les contrats existants result-flow, supervised-flow, daily-flow ou loop, montre état safe/warning/blocked, source, raison, commande et confirmation, puis délègue aux endpoints bornés déjà présents. Le navigateur n'invente aucune action et ne gagne aucune autorité.
• Workbench Action Outcome V1: après un clic sur l'action principale, le Workbench désactive les doubles clics, conserve l'issue locale de la dernière action, recharge les contrats Elora, affiche l'état du refresh et montre l'action suivante sélectionnée si elle existe. Le navigateur reste une surface: il ne crée pas d'action, ne calcule pas la policy et ne devient pas propriétaire du lifecycle.
• Workbench Guided Action Modal V1: l'action principale ouvre maintenant une modale guidée avec métadonnées, preview quand elle existe, note ou raison, override reason optionnel et confirmation exacte. Les valeurs sont transmises aux contrats CLI/API Elora; le cockpit ne gagne aucune autorité et les actions lifecycle réutilisent leur modale board.
• Natural Conversational Surface V1: les salutations et échanges légers restent des réponses directes provider-rendered quand le provider local est disponible, avec fallback local explicite sinon. Les questions sur Elora injectent désormais un self-model compact avant rendu modèle, et ok sans plan pending reste un accusé local plutôt qu'une confirmation d'exécution.
• Conversational Mission Orchestrator V1: le chat ne lance plus immédiatement une mission claire. Elora écrit un plan de mission conversationnel par session avec objectif, route, agent primaire, worker profile, livrables, gates qualité, risques, hypothèses et chemin d'inspection. Christophe peut ajuster, annuler, ou répondre go; seule cette confirmation déclenche le bridge d'exécution ou le fallback queue/policy/audit existant.
• Conversation-to-Execution Bridge V1: après go, le chat tente maintenant le lifecycle canonique elora-execute mission --apply --dispatch. Les routes prêtes créent une exécution focalisable dans le cockpit avec readiness et queue worker; les routes non prêtes restent en fallback queue explicite, sans prétendre avoir lancé une exécution.
• Conversation-to-Supervision Bridge V1: quand le bridge conversationnel crée une exécution, le tour chat attache maintenant une supervision_preview dry-run issue de elora-execute supervise. Le résultat indique immédiatement la prochaine action sûre, par exemple synchroniser la queue ou lancer une review, sans appliquer le superviseur ni muter mémoire, routing, provider ou policy. Si le chemin retombe sur la queue legacy, la supervision est marquée skipped explicitement.
• Post-Go Mission Run Loop V1: après go, Christophe peut demander ou ca en est ?, statut, point mission ou prochaine action. Le chat retrouve la dernière exécution de la session et lit elora-execute completion plus next-action en read-only. Le cockpit peut afficher Statut, Continuer, Synthese et Livraison comme raccourcis de surface qui repassent par elora-chat, sans sync implicite, worker caché, close, mémoire canonique, routing ou provider mutation.
• Natural Mission Acceptance Status: elora-acceptance check vérifie maintenant que le tour naturel ou ca en est ? après go passe bien par le statut déterministe read-only, et non par une réponse conversationnelle modèle. Le check couvre l'exécution retrouvée, la prochaine action, les actions cockpit sûres et les policies no-dispatch/no-memory/no-routing/no-provider.
• Mission Continuation Bridge V1: après un go conversationnel réussi, Christophe peut répondre continue, poursuis ou fais la suite. Le chat retrouve la dernière exécution de la session et applique elora-execute safe-continue --apply sans dispatch/close authority, puis retourne les étapes appliquées, la classe d'arrêt et la prochaine action opérateur.
• Natural Result Review Bridge V1: après mission ou supervision, Christophe peut répondre naturellement c'est bon, pas au niveau, rejette, prépare la synthèse finale, livraison finale ou clos la mission. Elora mappe ces phrases vers les contrats elora-execute existants: feedback proposal-grade, révision preview-only, synthèse/livraison déterministes et clôture preview-only. Aucun modèle, worker caché, bypass du Result Acceptance Gate ou mutation mémoire/routing/provider.
• V1 Closure Gate: la prochaine étape n'est plus d'ajouter un lot par défaut, mais de prouver le chemin opérateur normal et de corriger seulement les blocages, doublons, contradictions ou frictions qui empêchent un coeur V1 fiable. Les chantiers comme mémoire profonde, spécialisation fine des agents, Telegram, modèles additionnels et avatar futur peuvent continuer après un verdict ready, ready_with_known_limits ou blocked.
• Agent Capability Factory V1: elora-capability crée maintenant des Capability packs proposal-only pour nouvelles capacités domaine. Chaque pack contient agent stub, playbook skeleton, inputs, artefacts attendus, quality gates, readiness et promotion checklist sous ELORA_DATA_DIR/capability-factory/. promote-plan génère ensuite un Capability promotion plan avec patches candidats agent, playbook, compétence, excellence, fixture et harness. Rien n'est activé automatiquement et aucune mémoire, routing, provider ou config active n'est mutée.
• Cockpit Capability Inspection V1: la console Capabilities expose maintenant les packs elora-capability, leur validation, le doctor et la génération de dossiers de promotion derrière GENERATE CAPABILITY PROMOTION. Le navigateur reste une surface d'inspection: aucune activation d'agent, aucun worker lancé, aucune mutation mémoire, routing, provider ou config active.
• Agent Operational Matrix V1: elora-agent operational agrège inventaire agents, contrats Agent Excellence, fixtures eval et couverture elora-trial. La console cockpit Agent Ops affiche les états full_e2e_proven, readiness_only_by_policy, contract_ready_untrialed, setup_required et gaps sans lancer de worker ni muter mémoire, routing, provider, policy ou contrat.
• Agent Ops Action Bridge V1: elora-agent operational --json expose maintenant safe_actions et next_safe_action par agent, avec argv structuré et commande d'affichage séparée. Le cockpit Agent Ops lit /api/agents/actions et affiche les actions d'inspection, harness dry-run, readiness-only trial, Mission Pilot ou Golden Path prepare, sans dispatch worker, modèle, mutation mémoire, routing, provider, policy ou contrat.
• Agent Ops Safe Action Runner V1: POST /api/agents/action-run permet au cockpit de lancer une action sûre par agent et action_id. Le serveur relit la matrice elora-agent operational, valide allowlist CLI, type d'action, état sûr, flags non mutatifs et argv, puis exécute uniquement l'action déclarée par Elora. Le navigateur ne fournit jamais de commande shell arbitraire.
• Agent Readiness Coverage V1: onze agents auparavant contract_ready_untrialed reçoivent maintenant playbook, scénario elora-harness et trial readiness_only_by_policy. La matrice opérationnelle affiche désormais vingt trials: sept full E2E-proven, treize readiness-only par policy et zéro agent enabled encore contract_ready_untrialed. Cela améliore l'inspection et le cadrage sans prétendre que les spécialistes proposition/revue/curation disposent déjà d'une exécution déterministe complète.
• Mission Operator Loop V1: elora-execute operator-loop ajoute le contrat quotidien "quoi faire maintenant". Il enveloppe loop, board, gate summary et runbook opérateur, puis expose instruction, question de clarification, contrôles naturels et commandes déterministes sans modèle, dispatch, mutation mémoire/routing/provider ou autorité cockpit/chat.
• Daily Brief V1: elora-execute daily-brief dérive de daily-flow un brief opérateur compact: headline, focus, instruction, action recommandée, blockers, warnings, clarifications et commandes. Le Workbench l'affiche maintenant en premier pour répondre à "que faire maintenant ?" sans ajouter de logique d'autorité, modèle, dispatch, queue mutation, mémoire, routing, provider ou policy.
• Daily Pending Focus Hardening V1: quand le focus quotidien est une pending mission incomplète, operator-loop, daily-flow, daily-brief et supervised-flow conservent maintenant inputs manquants, question de clarification, actions disponibles et commandes clarify preview/start/dispatch. Elora montre le prochain geste exact au lieu de produire un blocage vague.
• Pending Mission Cancel V1: une pending mission obsolète peut maintenant sortir du focus actif sans perte d'historique. elora-execute pending-cancel prévisualise puis applique state=cancelled avec raison opérateur; le cockpit expose la même action derrière confirmation CANCEL PENDING MISSION. Aucun modèle, worker, dispatch, mémoire canonique ou routing n'est muté.
• Cockpit Mission Lifecycle V2: le Workbench expose maintenant une Mission Inbox filtrable: actives, pending, bloquées, annulées et done. elora-execute board sépare les items actifs de history_items; les pending missions annulées ou résolues restent inspectables avec leur raison ou état, mais ne reviennent pas dans le focus quotidien.
• Workbench Simplification V1: le premier niveau du Workbench garde maintenant seulement le chemin utile: brief, action principale, chemin quotidien, mission libre, inbox, mission active et runbook. Readiness profonde, stratégie, flux techniques, lanes, queue, détail exécution et JSON brut passent dans Détails avancés Workbench. Le cockpit reste inspectable sans transformer l'usage normal en tableau de bord saturé.
• Mission Clarification Quality V1: elora-execute mission conserve les questions de clarification simples pour compatibilité, mais expose maintenant des clarification_items structurés: input manquant, question, format attendu, exemple, raison et priorité. Le cockpit utilise ces items pour aider Christophe à répondre précisément, sans modèle, sans worker et sans mutation mémoire/routing/provider.
• Mission Flow Quality + Auto Resume V1: elora-execute mission expose maintenant plan_quality et auto_resume sur preview, pending, clarification, start et dispatch. Le cockpit affiche le gate qualité du plan, les blockers/warnings, l'état de reprise sûre et les commandes utiles avant le JSON brut. Rien ne s'exécute automatiquement: les confirmations START MISSION et DISPATCH MISSION restent obligatoires.
• Daily Mission Flow V1: elora-execute daily-flow agrège operator-loop, completion, arbitrage qualité et next-safe-action dans un contrat cockpit-ready. Le Workbench l'affiche comme carte détaillée pour montrer état du jour, focus, gates, qualité, readiness de réponse finale, phases et action recommandée; les boutons appellent seulement les endpoints bornés existants et les chemins apply gardent leurs confirmations exactes, sans modèle, mutation mémoire/routing/provider/policy ou autorité navigateur.
• Supervised Mission Execution V1: elora-execute supervised-flow ajoute un contrat Workbench inspectable. Il joint focus, route/playbook, agent si connu, runbook action, raison d'arrêt, confirmation requise et policy, puis expose le prochain geste utile sans exécuter, dispatcher, muter queue/mémoire/routing/provider/policy ou donner autorité au navigateur. Le chemin évite le scan complet elora-agent operational par défaut pour garder le cockpit réactif; l'affichage complet vit désormais dans les détails avancés.
• Strategic Daily Board V1: elora-strategy daily ajoute la carte stratégique quotidienne au-dessus du flux mission. Le Workbench affiche désormais focus, alignement stratégie/exécution/attention/contraintes, risques d'attention, séquences proposées et next best actions avant le Daily Mission Flow. Le chemin rapide reste read-only et garde le brief stratégique complet comme commande d'inspection séparée pour ne pas ralentir le cockpit.
• Operator Ritual V1: elora-strategy ritual --mode start|check|close reformate le Strategic Daily Board et la Weekly Review en cadence opérateur. Le Workbench peut maintenant guider le démarrage, le check de focus et la clôture d'une session avec question utile, état safe/warning/blocked, plan et commandes d'inspection, sans modèle, worker, queue ou mutation mémoire/routing/provider/policy.
• Operator Context Pack V1: elora-operator-state context expose un contrat read-only elora.operator_context.v1 sur check-ins, contraintes et engagements. elora-strategy daily le consomme maintenant pour afficher fraîcheur, posture, charge, contraintes et action de contexte dans le Workbench sans lancer le brief stratégique complet.
• Strategic Weekly Pack V1: elora-objectives ajoute un ledger local d'objectifs stratégiques dans operator-core, et elora-strategy weekly produit un pack read-only avec objectif principal, alignement objectif/next-action, risques de dispersion et actions command-backed. elora-strategy daily le consomme pour relier le travail du jour au cap de la semaine sans modèle, dispatch, mémoire canonique, routing ou provider mutation.
• Strategic Weekly Review / Objective Action V1: elora-strategy review-week vérifie maintenant les liens objectif/next-action, décisions, open loops et contexte opérateur. elora-strategy objective-action OBJECTIVE_ID prévisualise une next-action liée au cap, et --apply crée uniquement cette action operator-core avec strategy_objective_id=.... Le Workbench expose review, inspect objectif, preview et création confirmée par CREATE OBJECTIVE ACTION, sans modèle, worker, mémoire canonique, routing, provider, policy ou contrat agent muté.
• Result Quality Arbitration V1: elora-execute arbitrate agrège acceptance, result contract, artefacts, qualité, claim verification, review, comparaison de tentatives, feedback, synthèse et livraison dans un gate déterministe safe/warning/blocked/not_ready. Un worker terminé reste un signal, pas une acceptation.
• Redo Orchestrator V1: elora-execute redo devient le chemin opérateur pour demander une reprise quand un résultat est insuffisant. Il lit d'abord l'arbitrage qualité, refuse les reprises inutiles sur résultat accepté, exige une raison pour appliquer, puis délègue à revise en conservant attempt ledger, snapshot terminal et audit. Aucun modèle, mémoire, routing, provider ou contrat agent n'est muté.
• Final Operator Answer V1: elora-execute deliver produit maintenant .final_delivery.operator_answer avec réponse courte, faits, évaluation, recommandations, artefacts, limites, confiance, prochaine action et chemins d'audit. Le Markdown final est généré depuis cette même structure. Le delivery gate reste l'autorité: pas de modèle, pas de worker caché, pas de mémoire, pas de routing/provider/policy mutés.
• Cockpit Final Answer UX V1: la console Execution rend maintenant le Final Operator Answer comme carte opérateur dédiée: badges de delivery/result/confidence, réponse courte, faits, recommandations, limites, artefacts, prochaine action, chemins d'audit, copie du Markdown final et JSON replié. Le cockpit affiche mieux, mais ne valide rien seul.
• Mission Completion Flow V1: elora-execute completion ajoute un snapshot read-only qui indique où en est une mission avant clôture: résultat, acceptance, synthèse, livraison finale, feedback, outcome, learning, close, blockers, warnings et prochaine commande CLI existante. Le cockpit affiche cette carte sans lancer, clôturer, promouvoir ou muter quoi que ce soit.
• Mission Result Flow V1: elora-execute result-flow EXECUTION_ID consolide completion, arbitrage qualité, synthèse preview, delivery preview, réponse finale, feedback, blockers, warnings, artefacts, options de décision et prochaine action CLI. Le Workbench l'affiche comme Resultat mission pour décider reprendre, synthétiser, livrer, feedback, outcome, learning ou clôture, sans donner d'autorité au navigateur.
• External Runtime Update Check: Hermes est mis à jour vers 0.17.0 upstream 6b639bc2, statut Up to date. Les homes Hermes Elora restent en config_version 29 et la compression auxiliaire reste locale via supergemma4-31b-abliterated:q4_k_m. Le catalogue Hermes expose notamment computer-use et petdex, mais aucune capacité Hermes ne devient routable sans adapter/capability Elora. OpenCode reste le backend local-code optionnel; TimesFM local reste prêt; Ollama est présent mais daemon non lancé; ScrapeGraphAI reste optionnel tant que son venv n'est pas installé.
• Local Runtime Readiness V1: elora-ollama expose maintenant profiles et logs, elora-readiness matrix ajoute local_runtime, et le cockpit expose /api/local-runtime. Le registre suit local_ollama, local_llama_cpp et remote_ssh_llama_server. Un smoke OpenCode local valide le câblage du runtime supergemma4-31b-abliterated:q4_k_m, mais confirme aussi que les claims modèle doivent rester vérifiés par les gates.
• Runtime Selection & Worker Binding V1: elora-provider runtimes --json --probe expose les bindings entre providers locaux et profils runtime, avec capacité attendue et statut bloquant ou préférentiel. Les providers chat, reasoning et code peuvent pointer vers local_ollama sans rendre Ollama obligatoire; local_code_worker déclare ses backends native, local_model et opencode. Le cockpit expose la même vue via /api/provider-runtimes.
• Runtime-Aware Execution Selection V1: elora-provider select --capability code|reasoning|chat --task-class ... --json rend le choix runtime/provider inspectable sans appeler de modèle. elora-code backends select --json choisit ensuite le backend code local: artefact natif déterministe, modèle local code/raisonnement ou OpenCode. Un modèle plus lourd comme GLM-5.2 ou Qwen peut être branché via ELORA_LOCAL_CODE_BASE_URL et ELORA_LOCAL_CODE_MODEL, mais Elora ne lance pas implicitement un runtime lourd et ne remplace pas les gates qualité par une inférence.
• GLM-5.2 Local Code Candidate V1: le cookbook elora-models recommend --task code --json et le provider local_code_model déclarent maintenant GLM-5.2 comme candidat recommandé pour le code agentique local. L'activation reste explicite: le runtime local doit servir le modèle, ELORA_LOCAL_CODE_MODEL doit pointer vers son id exact, et les artefacts/diffs/tests restent sous local_code, OpenCode et les gates Elora.
• Local Code Runtime Activation V1: elora-code runtime status --probe --json vérifie le endpoint local et la présence du modèle configuré sans inférence. elora-code runtime smoke --execute-local --json lance un appel modèle minimal seulement sur demande explicite, sans worker dispatch, sans mutation repo/routing/provider/mémoire, sans auto-download et sans auto-launch.
• Local Code Runtime Cockpit Gate V1: elora-readiness matrix ajoute la source local_code_runtime, elora-execute mission bloque le backend local_model quand le runtime code est dégradé, et le cockpit expose /api/local-code-runtime. Status et probe restent diagnostic-only; le smoke local exige SMOKE LOCAL CODE RUNTIME parce qu'il appelle réellement le modèle.
• Local Runtime Activation Profiles V1: elora-ollama launch-plan --all --json transforme les profils local_ollama, local_llama_cpp, local_dgx_gb10_llama_server et remote_ssh_llama_server en commandes opérateur copiables: env, launch, probe, smoke et binding local_code. Le cockpit expose ce plan via /api/local-runtime, sans auto-launch, sans systemd et sans inférence.
• Validation Suite Split V1: scripts/test.sh est maintenant découpé en suites opératoires. fast devient le défaut pour les validations fréquentes; runtime, cockpit, execution, agents et e2e ciblent les sous-systèmes; telegram exige ELORA_TEST_TELEGRAM=1; full conserve la régression historique longue.
• Cockpit Validation Console V1: le cockpit expose /api/validation, /api/validation/run et une console Validation. Les suites restent whitelistees et lancées par scripts/test.sh; les runs sont conservés sous ELORA_DATA_DIR/validation/runs avec stdout, stderr, exit code, durée, commande et policy. Telegram et full exigent une confirmation explicite, et le navigateur ne peut pas fournir de commande arbitraire.
• Conversational Intent Classifier V1: elora-intent classify ajoute une couche locale de compréhension des tours courts et ambigus. Les règles déterministes restent prioritaires; le modèle local est optionnel, local-only et classifier-only. Le chat expose intent_classification et ne peut transformer une intention reconnue en action qu'en repassant par les contrats déterministes existants.
• Natural Mission Intake Hardening V1: les confirmations, ajustements, annulations, demandes de statut, continuations et jugements courts passent maintenant par le contrat elora.intent.v1. Les anciens raccourcis directs de elora-chat sont désactivés par défaut; ils ne restent utilisables qu'en diagnostic. Le cockpit continue de renvoyer les actions naturelles vers elora-chat, sans posséder l'autorité.
• Conversational Mission Control V2: chaque tour elora-chat expose désormais un objet mission_control compact avec état safe/warning/blocked, prochaine action opérateur, intention reconnue, route, agent, ids d'exécution et limites de policy. Le cockpit rend cette carte directement dans les messages. Les ajustements naturels comme ajoute une synthèse courte restent proposal-only tant que Christophe n'a pas confirmé le plan; seul le tour confirmé peut porter worker_dispatch=true.
• Daily Mission Conversation Bridge V1: le cockpit affiche maintenant une carte Pont conversation mission sous les réponses de contrôle mission. Elle montre ce qu'Elora a compris, le contrat déterministe utilisé, l'exécution ou la queue ciblée, la commande utile, la prochaine action et les boutons d'inspection. Le panneau Intention comprise expose aussi source, confiance, safe action, inputs manquants et questions utiles sans ouvrir le JSON. Le navigateur ne classe pas les phrases lui-même: il lit seulement les métadonnées elora-chat et renvoie les raccourcis vers le même chemin conversationnel.
• Mission Flow E2E Harness V1: elora-e2e run daily_mission_conversation_bridge_local --json prouve maintenant le chemin quotidien complet depuis une conversation naturelle: plan, go, exécution lifecycle, queue worker, statut déterministe, sync, safe continuation, feedback proposal-grade, synthèse, livraison et close preview. Le scénario reste isolé et vérifie l'absence de Telegram, Hermes, Codex, provider distant, inférence modèle, mémoire canonique, mutation routing/provider et autorité cockpit.
• Daily Mission Workbench V1: le Workbench ajoute maintenant Brief operateur puis Chemin quotidien près du haut de l'écran. Le brief vient de daily-brief; le chemin quotidien combine état daily-flow, focus, prochaine action sûre, preuve natural_daily_loop_e2e chargée quand elle existe, badges no-model/no-authority et prochaine commande utile copiable. Les boutons Accept et Verifier V1 Core restent explicites; aucun gate lent n'est lancé silencieusement.
• Daily Mission Workbench Action Runner V1: Chemin quotidien expose maintenant Actions quotidiennes. Les actions issues de daily-flow.daily_actions sont groupées par inspection, continuation, worker/queue, résultat, feedback et clôture. Les actions sûres peuvent être lancées directement; les mutations et jugements passent par la modale Workbench, avec confirmations exactes et audit de dernière action.
• Daily Mission Workbench UX Tightening V1: le premier niveau du Workbench répond maintenant à Que faire maintenant ?, montre le geste recommandé et affiche le cycle Objectif -> Plan -> Go -> Suivi -> Continuer -> Résultat -> Feedback -> Livraison. Les preuves, commandes, gates et actions secondaires restent disponibles dans Détails avancés.
• Mission Safe Continuation V1: elora-execute safe-continue devient le geste quotidien "avance jusqu'au prochain arrêt sûr". Il encapsule elora-execute supervise, expose un contrat plus lisible, avance seulement les étapes déterministes bornées et stoppe avant dispatch, close, feedback, learning, révision, clarification ou jugement opérateur. Le chat continue et le Workbench l'utilisent; le cockpit exige SAFE CONTINUE. Mission Supervisor reste la primitive technique inspectable avec SUPERVISE EXECUTION.
• Mission V0 Acceptance: elora-acceptance vérifie le chemin quotidien minimal sans dépendre de Telegram, Hermes, Codex, provider distant, modèle local ou worker réel. Le gate couvre demande naturelle, plan conversationnel, confirmation go, statut post-go déterministe, continuation, feedback proposal-grade, mission preview sûre, clarification utile, Golden Paths, Mission Pilots et endpoints cockpit.
• Field Mission Rehearsal V1: elora-acceptance field ajoute un banc de répétition pratique pour les missions terrain: analyse de site, code local, support triage, documentation update, forecast TimesFM, brief de décision en état judgment_required et clarification d'inputs manquants. Le contrôle reste isolé, dry-run-only, sans modèle, sans dispatch worker, sans Telegram/Hermes/Codex, sans mémoire canonique, routing ou provider mutation; il prouve le cadrage et les boundaries, pas la qualité finale d'un livrable produit. Le cockpit l'expose maintenant dans la console Accept via le bouton Field rehearsal et l'endpoint POST /api/acceptance/field, sans transférer d'autorité au navigateur.
• Field Mission Execution V1: les checks du Field Mission Rehearsal sont reliés aux Mission Pilots. Quand une classe terrain expose un Golden Path, le cockpit charge le contrat elora-execute mission-pilot, affiche ses inputs, puis propose Preflight, Dry-run, Start et Dispatch. Les actions repassent par elora-execute golden-run; les confirmations, gates, no-model, no-memory et no-authority restent inchangés.
• Mission Daily Loop E2E V1: elora-acceptance check ajoute le scénario composite natural_daily_loop_e2e. Il prouve dans une racine isolée qu'un objectif naturel peut traverser plan, go, statut déterministe, safe-continue, feedback opérateur et readiness de réponse finale avec commandes synthèse/livraison visibles, sans modèle, worker caché, mémoire canonique, routing/provider mutation ou autorité cockpit. Le cockpit rend maintenant cette preuve dans une carte Daily Loop dédiée dans Accept, et la réexpose dans V1 Core Readiness quand la source acceptance est chargée.
• Mission Pilots V1: elora-execute mission-pilots et mission-pilot transforment les chemins Golden Path certifiés ou prouvés en surface pratique de lancement. Le cockpit expose une console Pilots avec readiness, preuve E2E, certification, inputs requis, artefacts attendus, quality gates et actions prepare, dry-run, start, dispatch ou pilot readiness. L'inventaire est read-only et toutes les actions repassent par golden-run, golden-pilot et les gates existants.
• Odysseus-Inspired Local Capability Hardening V1: elora-models ajoute un cookbook local sans téléchargement ni benchmark implicite; elora-provider compare compare des providers en dry-run/proposal-only; elora-context-trust enveloppe web, PDF, Markdown, email, OCR ou transcript comme contexte non fiable data-only; elora-readiness degraded expose ce qui reste utilisable quand Telegram, Hermes, Ollama, PostgreSQL ou un provider distant sont absents.
• Context Boundary Integration V1: les evidence packs exposent maintenant external_context_boundary, et les Markdown mission packs transmettent aux workers wrapped_content sous ELORA_UNTRUSTED_CONTEXT. Les fichiers Markdown restent utiles comme dossiers vivants, mais ils ne deviennent ni instructions système, ni mémoire canonique, ni règle de routing.
• État après certification: elora-execute golden-pilots --json rapporte runtime_e2e_proven=7, certified=7, ready_to_certify=0, certification_gaps=0. security_advisory_response et decision_brief restent readiness-only par policy car ils exigent un jugement opérateur.
• Preuves et audit: les fichiers runtime restent dans sx-core-blueprint-kit/var/agents/trials/runs/, volontairement hors Git. Le snapshot suivi côté repository est documenté dans sx-core-blueprint-kit/docs/GOLDEN_PATH_CERTIFICATION_STATUS.md.
• Conséquence opératoire: Elora peut maintenant afficher clairement les chemins certifiés dans le cockpit et éviter de confondre "je sais router cette mission" avec "j'ai prouvé que ce chemin local complet fonctionne".