Sessions
Chaque conversation peut devenir un contexte navigable avec titre, source, tours, artefacts et liens vers les missions.
operator_surface
Pourquoi Telegram ne suffit pas.
Telegram est utile pour la continuité. Un vrai cockpit local est nécessaire pour naviguer dans les sessions, séparer les contextes, brancher une conversation, attacher des artefacts et inspecter les résultats.
Branches
Une demande peut partir dans une nouvelle session sans détruire la conversation d'origine.
Artefacts
Images, fichiers, outputs, reports et résultats doivent rester consultables et réutilisables.
Navigation opérateur
L'inspecteur privilégie maintenant les actions fréquentes: Workbench, Flow, Mission, Execution, Playbooks, Learning et Vider. Les diagnostics, tests agents et fonctions admin restent disponibles dans des groupes déroulants pour réduire l'entassement sans cacher les contrats CLI.
Dialogue mission
Le chemin quotidien n'oblige pas à commencer par les consoles. Dans le chat, une mission claire produit d'abord un plan conversationnel: objectif, route, agent, worker profile, livrables, quality gates, risques et inspection. Christophe peut confirmer, ajuster ou annuler naturellement; le tour est classé par elora.intent.v1, puis Elora repasse par les contrats CLI déterministes. Après une confirmation valide, le Conversation-to-Execution Bridge tente d'abord le lifecycle elora-execute mission --apply --dispatch: si le chemin est prêt, le chat retourne l'exécution, la queue worker et une supervision_preview dry-run avec la prochaine action sûre. Christophe peut demander ou ca en est ?, statut ou prochaine action: Elora relit alors elora-execute completion et next-action en read-only, sans sync implicite, sans worker caché et sans mutation. Il peut ensuite demander de continuer: le Mission Continuation Bridge applique elora-execute safe-continue, c'est-à-dire une continuation sûre jusqu'au prochain arrêt réel, sans dispatch ni clôture. Une phrase comme c'est bon, pas au niveau, rejette ou prépare la synthèse finale passe par le Natural Result Review Bridge: feedback proposal-only, révision en preview, close en preview, jamais de bypass du Result Acceptance Gate. Les réponses de contrôle peuvent afficher une carte Pont conversation mission avec un panneau Intention comprise: intent, source, confiance, safe action, target execution, inputs manquants, questions utiles et rappel classifier-only deviennent visibles sans ouvrir le JSON. La carte Mission control reste disponible pour l'état safe/warning/blocked, les actions naturelles et les raccourcis. Quand un plan attend confirmation, le cockpit peut afficher Lancer le plan, Ajuster et Annuler; après confirmation, il peut afficher Statut, Continuer, Synthese et Livraison. Ces boutons ne dispatchent rien eux-mêmes: ils renvoient simplement un message de contrôle au même chemin elora-chat. La carte est inspectable, mais ne possède aucune autorité d'exécution, mémoire, routing ou provider. Le cockpit peut focaliser directement l'exécution et proposer Continuer mission. Si la readiness, la policy, la route ou un input bloque le lancement, le bridge conserve le refus structuré et ne crée ni exécution, ni worker, ni queue legacy. Le plan reste disponible: fournir une URL ou rendre la capacité requise prête permet de reprendre naturellement la même mission.
Mission Workbench
La vue par défaut suit maintenant une règle simple: le quotidien visible, l'inspection profonde à la demande. Le premier niveau affiche Brief operateur, Action principale Workbench, Chemin quotidien, Mission libre, Mission Inbox, mission active et runbook opérateur. Christophe voit donc quoi faire maintenant, pourquoi, quelle action est sûre, comment lancer un nouvel objectif, ce qui est actif et ce qui attend une décision. Quand une session est ouverte, le Workbench dérive son execution_id du transcript, affiche un Scope session explicite et interroge elora-execute loop --focus: une mission globale plus récente ne peut donc ni remplacer l'inspection visible, ni recevoir l'action destinée à cette conversation. Le changement de session invalide les lectures globales ou précédentes encore en vol, purge l'exécution et le résultat sélectionnés, puis recharge le scope actif; une réponse ou action asynchrone tardive ne peut plus réintroduire un ancien blocker dans l'inspecteur. Sans session active, la priorité globale déterministe reste disponible. Les diagnostics profonds restent accessibles dans Détails avancés Workbench: état opérationnel, readiness, stratégie, flux techniques, lanes, queue, exécution sélectionnée et JSON brut. Si un endpoint read-only échoue, la vue passe en mode dégradé et affiche l'endpoint fautif au lieu de masquer tout le cockpit derrière une erreur globale. Les boutons appellent uniquement les contrats CLI/API existants; le navigateur n'invente aucune action et ne possède ni mémoire, ni routing, ni policy, ni provider.
Chemin quotidien
Chemin quotidien condense le chemin normal avec une première question simple: Que faire maintenant ?. La carte met en avant l'action recommandée, puis affiche le cycle compact Objectif -> Plan -> Confirmation -> Suivi -> Continuer -> Résultat -> Feedback -> Livraison. Les preuves natural_daily_loop_e2e, badges no-model/no-authority, commandes et actions secondaires restent accessibles dans Détails avancés pour ne pas transformer l'usage quotidien en console d'audit. Actions quotidiennes reste command-backed par elora-execute daily-flow: les actions read-only ou dry-run peuvent s'exécuter directement; les mutations, jugements, notes requises, overrides ou confirmations exactes passent par la modale Workbench et gardent les confirmations CLI/API. Mission libre permet de donner un objectif, prévisualiser, démarrer ou demander le dispatch via elora-execute mission, sans quitter l'écran de départ et sans que le cockpit possède le routing, la mémoire, les providers ou les confirmations.
Operator Ritual
elora-strategy ritual --mode start|check|close reste disponible dans Détails avancés Workbench. Cette carte donne la question utile, l'état safe/warning/blocked, le plan de cadence et les commandes d'inspection pour démarrer une session, vérifier le focus ou clore proprement. Elle ne lance aucun modèle, worker ou queue; elle reformate les contrats existants sans polluer le premier niveau.
Strategic Daily Board
elora-strategy daily reste disponible en inspection avancée. Cette carte répond à la question quotidienne: qu'est-ce qui mérite mon attention maintenant, pourquoi, et quelle commande bornée existe déjà ? Elle agrège focus, alignement stratégie/exécution/attention/contraintes, risques d'attention, séquences proposées et next best actions. Elle consomme le Strategic Weekly Pack et l'Operator Context Pack sans lancer le brief stratégique complet. Le chemin quotidien reste plus court; le brief stratégique complet reste accessible séparément par elora-strategy brief --json.
Daily Mission Flow
elora-execute daily-flow reste le contrat source du brief quotidien et du chemin visible. Sa carte technique complète vit maintenant dans Détails avancés Workbench: boucle opérateur, completion, arbitrage qualité, next-safe-action, readiness de réponse finale, phases, pending missions et commandes clarify / pending-cancel. Le contrat reste read-only: pas de modèle, pas de dispatch implicite, pas de mémoire, pas de routing, pas de provider et pas d'autorité navigateur.
Supervised Mission Execution
elora-execute supervised-flow reste disponible dans les détails avancés: focus, route/playbook, agent si connu, action existante recommandée, raison d'arrêt, confirmations et limites de policy. Le premier niveau affiche déjà l'action principale; la carte de supervision sert donc à comprendre pourquoi Elora doit continuer, s'arrêter ou demander un jugement. C'est une carte read-only et action-selection-only: elle ne lance rien seule, ne dispatche pas, ne mute pas la queue, la mémoire, le routing, les providers ou la policy.
Mission Result Flow
elora-execute result-flow EXECUTION_ID ajoute la carte Resultat mission dans le Workbench. Elle consolide completion, arbitration, synthèse preview, delivery preview, réponse finale, feedback, blockers, warnings, artefacts, options de décision et prochaine action CLI existante. Elle ne valide rien seule: accepter, demander reprise, sauver une synthèse, sauver une réponse, enregistrer l'issue, capturer le learning ou clôturer repasse par les endpoints existants et leurs confirmations.
Auto-contrôle sémantique
Pour une recherche publique, le cockpit expose le contrôle effectué avant le jugement opérateur: statut, score, nombre de tentatives, reprises automatiques, brouillon source et critique local. passed avec zéro reprise signifie que le premier brouillon déterministe a été relu et accepté; un nombre supérieur indique qu'Elora l'a corrigé avant de le présenter. degraded signifie que le modèle critique était indisponible et que seuls les contrôles déterministes ont pu être garantis. Christophe juge ensuite l'utilité réelle du livrable; il ne remplace pas l'auto-contrôle technique et sémantique d'Elora.
Queue / results
Le cockpit affiche l'état des workers, les erreurs, les retries, les résultats, les chemins de fichiers et les artefacts déclarés par sxqueue result. Les artefacts de résultat peuvent être ouverts en lecture seule par index via le contrat CLI elora-result artifact: JSON natif, qualité worker, synthèses, claims ou sorties déterministes.
Support triage
La console Support appelle POST /api/support/triage, qui délègue à ./bin/elora-support. Christophe colle un ticket, un contexte et une procédure éventuelle; le worker local produit classification, evidence gaps, next actions, rapport et brouillon client avec disclosure IA. Le cockpit affiche les artefacts, mais ne contacte personne, ne modifie aucun ticket, n'écrit pas la mémoire canonique et ne change ni routing, ni provider.
Worker Registry
La console Workers expose GET /api/workers, GET /api/worker, POST /api/worker/run, GET /api/worker/lifecycle, POST /api/worker/attach et POST /api/worker/feedback. Elle liste les workers locaux queue-compatibles: site, docs, code local, forecast, prospection StackX et support. Le navigateur rend les champs, le serveur écrit un prompt temporaire privé, lance le CLI worker, puis relit le rapport et les artefacts. Chaque run direct conserve maintenant lifecycle.json, events.jsonl, preflight gate, result contract, quality gate, learning hint et feedback opérateur proposal-only. Les workers directs écrivent aussi un result.json contractuel: payload natif conservé, native_result séparé, deliverable validable par elora-result, fichiers obligatoires et manifest. Les boutons Preview execution et Attacher execution appellent elora-execute attach-worker: preview est read-only, apply exige ATTACH WORKER et crée une exécution direct_worker. Une fois attachée, le cockpit ouvre directement l'exécution et affiche les raccourcis de suite: cycle guidé, synthèse, supervision preview, livraison, feedback, outcome et close restent contrôlés par les gates elora-execute. elora-scrapegraph est visible comme capacité directe, mais n'est pas lancé par ce endpoint V1. local_code reste en analyse read-only par défaut et exige RUN LOCAL CODE WORKER pour un mode potentiellement mutating.
Patch Review local_code
Quand un worker local_code produit un diff, le cockpit expose elora-code patch inspect/decide dans les vues résultat, queue et exécution. Christophe peut lire les fichiers modifiés, inspecter le diff borné, prévisualiser une décision puis enregistrer accepted, needs_revision ou rejected avec confirmation DECIDE PATCH. Le cockpit n'applique pas le patch, ne commit rien et ne remplace pas le gate d'acceptation.
Evidence Inspector
La console Evidence inspecte un run playbook, une exécution ou une queue via elora-evidence inspect. Elle affiche la qualité du contexte L0/L1/L2/L3, les issues, warnings, recommandations, questions utiles et context quality gate sans écrire la mémoire, changer le routing ou dispatcher quoi que ce soit.
Operator Flow V2
La console Flow reste l'écran transversal: elle rassemble Work Intake, Sequence Execution Bridge, Mission Control, Execution Handoff, queue, playbooks, review, Learning Review Inbox, feedback et Improve pour montrer les chemins ouverts sans créer une nouvelle autorité.
Control Plane
La console Control appelle seulement eloractl status --json et eloractl doctor --json. Elle affiche process, queue, approvals, mémoire, provider par défaut, agent par défaut, commandes requises, fichiers et chemins, avec un contrat surface_only: inspection, pas mutation.
Readiness Matrix
La console Readiness appelle elora-readiness matrix --json. Elle normalise Control Plane, commandes locales, providers, agents, Agent Excellence, playbooks, harnesses, mission runtime, context files et queue en ready, warning ou blocked. Elle expose operational_core_status pour le chemin cockpit praticable et cockpit_direct_status pour le chemin local cockpit/CLI sans dépendre de Telegram ni du daemon long-running. Les fast doctors agents/playbooks/harnesses gardent l'affichage rapide; les doctors profonds restent disponibles pour audit. Les timings de source et slow_sources rendent les lenteurs inspectables. Les providers connectés optionnels, agents désactivés par setup, playbooks optionnels dégradés ou registre Markdown absent deviennent des advisory_warnings quand ils ne bloquent pas le travail local direct. elora-readiness cockpit-direct-smoke vérifie le chemin avec mission dry-run, board et loop, sans worker ni mutation. Le bouton Verifier V1 Core appelle /api/readiness/core-v1: en mode cockpit il utilise core-v1 --fast, elora-acceptance doctor et timeouts bornés pour répondre vite à "Elora peut-elle travailler maintenant ?". La validation release complète reste elora-readiness core-v1 --json sans --fast et elora-acceptance check --json.
Runtime code local
La Readiness expose maintenant local_code_runtime depuis elora-code runtime status. Le cockpit peut appeler /api/local-code-runtime pour lire le status, lancer un probe /v1/models sans inférence, ou effectuer un smoke modèle uniquement après confirmation exacte SMOKE LOCAL CODE RUNTIME. Si ce runtime est dégradé, le backend local_model est bloqué pour les missions code, mais les artefacts natifs déterministes restent possibles.
Validation Console
La console Validation expose les suites scripts/test.sh depuis le cockpit: fast, runtime, cockpit, execution, agents, e2e, telegram et full. Chaque lancement passe par une allowlist serveur, enregistre stdout/stderr, statut, durée, exit code et policy sous ELORA_DATA_DIR/validation/runs, puis reste réouvrable. Telegram et full exigent une confirmation explicite. Le navigateur ne peut pas fournir de commande arbitraire: l'autorité reste scripts/test.sh.
Work Intake
La console Intake agit comme Mission Composer: elle transforme une intuition en objet local puis en séquence exécutable via elora-intuitions. Elle peut ensuite prévisualiser ou créer une exécution depuis la séquence via Sequence Execution Bridge. Capture, séquence et exécution restent dry-run d'abord; les écritures réelles exigent CAPTURE INTUITION, CREATE SEQUENCE ou EXECUTE SEQUENCE.
Mission Control
La console Mission lit elora-operate: brief, triage, next, plan-day et handoff. Le handoff est dry-run par défaut; l'application exige APPLY HANDOFF et ne fait que marquer une next action en doing.
Strategic Operating Loop
elora-strategy ajoute une couche de brief stratégique, rituel start/check/close, board quotidien, review semaine, triage texte, proposition de séquence et review au-dessus de Mission Control et du pipeline intuition. Il ne lance pas de modèle, ne dispatche pas de worker et ne mute pas la mémoire; sequence --apply écrit seulement dans le pipeline intuition après demande explicite, et objective-action --apply crée seulement une next-action operator-core liée à l'objectif.
Golden Path Missions
La console Execution affiche un catalogue déterministe de missions standard via elora-execute golden-paths et /api/execution/golden-paths: analyse de site, recherche web, prospection StackX, analyse documentaire, mise à jour docs, code local, forecast, support, sécurité et decision brief. Chaque carte expose playbook, trial, agent, inputs requis, artefacts attendus, quality gates, policy et statut ready, degraded, judgment_required ou blocked. Le Golden Path Pilot ajoute une couche de preuve: elora-execute golden-pilots et /api/execution/golden-pilots relient chaque carte à elora-trial, au mapping harness/E2E et au dernier run stocké. La Mission Pilot ajoute la vue pratique: elora-execute mission-pilots et /api/execution/mission-pilots montrent les chemins réellement lançables maintenant, leurs inputs, preuves, artefacts attendus et commandes sûres. La Golden Path Certification ajoute un état séparé: ready_to_certify, readiness_recorded, certified ou gap. Le bouton Pilot lance par défaut un check readiness-only; Certifier ready lance les full E2E locaux des chemins prêts derrière confirmation CERTIFY GOLDEN PATHS. Les écritures restent limitées aux fichiers de run trial et aux learning proposals.
Golden Path Runner
elora-execute golden-run affiche des champs structurés générés depuis le schema CLI; les exemples restent des placeholders, pas des valeurs exécutables. Il valide les champs, rend la mission, expose le gate, les questions utiles, les artefacts attendus et la policy avant le JSON brut, puis délègue à elora-execute cycle. Un start appliqué attache golden_path_runner et golden-path-run.json à l'exécution; le dispatch direct reste autorisé seulement pour les chemins ready.
Mission libre
La console Execution peut convertir une mission déjà claire en next action virtuelle, plan Execution Handoff, start réel et dispatch optionnel via elora-execute mission. Le sélecteur peut rester en auto-routing ou forcer un mission preset via --playbook: site, StackX, documentation, code local, support, sécurité, décision ou forecast. Preview ne mute rien et affiche un Mission preflight, Mission readiness, un Plan quality gate et un Mission auto-resume: texte original, texte effectif, composition depuis contexte récent quand elle est sûre, inputs manquants avant/après, hypothèses, statut safe, warning ou blocked, source de route, agent primaire, worker reality, artefacts attendus, gates qualité, prochaine action et commande de reprise sûre. Start exige START MISSION; start + dispatch exige DISPATCH MISSION. Si une mission appliquée manque encore d'inputs, Elora crée une pending mission inspectable; le cockpit peut afficher les questions enrichies avec format attendu, exemple et raison, prévisualiser la réponse, puis relancer le même pipeline après clarification.
Guided Mission Runner
elora-execute cycle rassemble mission, exécution, evidence, result acceptance et Next Safe Action dans un guide unique. Le cockpit peut prévisualiser une mission libre, démarrer le chemin existant ou relire une exécution en affichant étape courante, questions, blockers, commande utile et policy. Le cycle ne lance pas de modèle, ne dispatche pas en secret, ne ferme rien, ne promeut aucun learning et ne mute ni mémoire, ni routing, ni providers.
Mission Execution Loop
elora-execute loop lit le board, choisit l'item prioritaire par règles déterministes, affiche l'état safe, warning, blocked ou idle, puis propose une action existante du board. Il expose aussi une mission_timeline lisible: intake, evidence/context, dispatch, résultat/vérification, acceptance et learning/closure, plus un gate_summary pour contexte, dispatch, result acceptance, result contract et claims, et un operator_runbook pour transformer cette lecture en procédure opérateur. Le cockpit rend cette boucle avant les lanes pour répondre à la question pratique: quoi traiter maintenant, où en est la mission, qu'est-ce qui bloque, quelle action CLI déjà autorisée peut être lancée, et quel résultat attendre après l'action ? La boucle reste read-only: pas de worker lancé, pas de queue mutée, pas de clôture, pas de promotion learning, pas de mémoire ou routing modifié.
Mission E2E
La console E2E appelle elora-e2e via /api/e2e et /api/e2e/run. Elle vérifie hors production qu'un chemin local complet fonctionne réellement: mission libre, dispatch, queue, worker déterministe, result contract, sync, review, learning preview, feedback preview et close readiness. Le scénario daily_mission_conversation_bridge_local prouve aussi le chemin quotidien conversationnel complet: plan elora-chat, go, exécution lifecycle, queue worker, statut déterministe, sync, safe continuation, feedback proposal-grade, synthèse, livraison et close preview. Le cockpit liste les scénarios, lance un scénario ou tous les scénarios, affiche phases, erreurs, fichiers produits, acceptance gate et mutation policy. Il ne calcule pas la fiabilité et n'accepte pas de commande arbitraire.
Mission V0 Acceptance
La console Accept appelle elora-acceptance via GET /api/acceptance, POST /api/acceptance/check et POST /api/acceptance/field. Elle répond à la question pratique: Christophe peut-il donner un objectif naturel, recevoir un plan, dire go, demander ou ca en est ?, continuer, juger le résultat et voir les commandes de synthèse/livraison disponibles sans inspecter dix consoles ? Le check rapide crée une racine isolée et vérifie maintenant un scénario composite natural_daily_loop_e2e: plan conversationnel, go explicite, statut post-go déterministe, safe-continue, feedback proposal-grade, previews de synthèse/livraison finale, clarification utile, Golden Paths et Mission Pilots. La console rend ce scénario dans une carte Daily Loop dédiée: étapes, politique de continuation, feedback, état de completion, previews et badges no-model/no-authority. Le bouton Field rehearsal lance aussi le Field Mission Rehearsal: analyse de site, code local, support, documentation, forecast, brief de décision et clarification d'inputs manquants sont affichés avec gates, policy et questions utiles. Chaque check terrain est maintenant enrichi par le Mission Pilot correspondant quand il existe: le cockpit affiche les champs d'inputs, puis propose Preflight, Dry-run, Start et Dispatch. Ces boutons repassent par elora-execute golden-run et gardent les confirmations existantes. Cette répétition prouve le cadrage et les boundaries, pas la qualité finale d'un worker réel. Le même détail Daily Loop est repris dans V1 Core Readiness quand il est chargé. Le statut post-go relit completion et next-action en read-only; il ne retombe pas en conversation modèle. Le gate ne dépend pas de Telegram, Hermes, Codex, provider distant ou modèle, et n'écrit ni mémoire canonique, ni routing, ni provider. Le bouton E2E profond est séparé et demande une action explicite.
Mission Live Run / Mission Operations
La console Live appelle elora-live-run via /api/live-run et /api/live-run/run. Elle démarre un vrai cockpit loopback isolé, extrait le token local, vérifie que l'API refuse l'absence de token et une mauvaise confirmation, puis traverse les APIs cockpit jusqu'au worker local sxcore run-once, review, delivery, feedback, outcome, learning et close. Elle affiche maintenant un contrat mission_operations: compris, contexte, routing, gates, état safe/warning/blocked, timeline, artefacts et prochaines actions. Les phases lentes restent dans operator_friction; elles ne transforment pas seules une mission acceptée et clôturée en warning. Elle prouve le chemin opérateur cockpit; elle ne donne aucune autorité au navigateur.
Execution Handoff
La console Execution projette les contrats de elora-execute sans devenir une seconde orchestration. Une mission passe par plan, démarrage, dispatch ciblé, synchronisation, review, Result Acceptance, synthèse, livraison, jugement opérateur, learning proposal-only et clôture. Le Mission Lifecycle Board sépare les missions actives de l'historique résolu ou annulé et expose uniquement des actions déclarées par la CLI.
elora-execute synthesize sélectionne d'abord l'artefact métier accepté. Sa preview reste extractive et sans inférence; sur sauvegarde, un provider local peut produire un rendu naturel tracé, avec fallback extractif immédiat. elora-execute deliver applique ensuite le gate final et conserve les preuves détaillées dans le JSON plutôt que de les imposer dans la conversation.
Continuer mission applique seulement le prochain geste borné déjà autorisé: worker attaché, runtime local, sync, review ou continuation sûre. Si les gates déterministes refusent le livrable et recommandent une correction, la Bounded Quality Convergence relance automatiquement cette même queue, synchronise le nouveau run_id et refait la review. Elle s'arrête dès que les critères passent, que le score stagne ou régresse, ou que le plafond total de trois révisions est atteint. À ce véritable point de décision, le cockpit affiche un Operator Judgment Contract: question concrète, constats utiles, tentative, évolution du score, recommandation et choix bornés. Chaque reprise repart de la source canonique de la mission, transmet les contrôles qualité réellement échoués et reste dans l'Attempt Ledger. Dispatch arbitraire, acceptation forcée, close, feedback, learning, mémoire, routing et providers ne deviennent jamais implicites. Le Redo Orchestrator et le Revision Learning Bridge gardent toute la convergence inspectable.
Final Operator Answer
La livraison finale ne se limite plus à un snapshot technique. Le coeur déterministe sélectionne d'abord l'artefact métier accepté; un rendu local optionnel peut ensuite le transformer en réponse naturelle avec provenance provider/modèle et fallback extractif. Le Markdown montre le contenu demandé, les limites utiles et l'artefact principal. Gates, fichiers secondaires et audit restent disponibles dans le JSON replié. Le cockpit aide à lire et décider; il ne valide, ne clôture et ne promeut rien seul.
Mission Completion
elora-execute completion relit une exécution et agrège résultat, acceptance, synthèse, livraison finale, feedback, outcome, learning, close et Next Safe Action. Le cockpit affiche état courant, sévérité, raison, blockers, warnings et action CLI recommandée. C'est un snapshot read-only: il ne lance rien, ne ferme rien, ne promeut rien et ne mute ni mémoire, ni routing, ni provider, ni policy.
Exploration preview
Depuis une exécution, le cockpit peut appeler elora-execute explore EXECUTION_ID --kind collision|candidates --dry-run --json. Les boutons Explore collision et Explore options lisent le snapshot playbook/exécution, préparent des pistes non évidentes et les affichent en JSON. Ce sont des propositions: pas de dispatch worker, pas de mémoire canonique, pas de routing, pas de provider mutation et pas de preuve.
Next Safe Action
elora-execute next-action lit l'état d'une exécution et propose le prochain geste sûr: preview dispatch, démarrage explicite du runtime local, lancement ciblé d'une queue déjà attachée, sync queue, review, claims, feedback, outcome, learning, redo, close ou clarification. C'est une recommandation déterministe et read-only. Si un worker Hermes dépend d'Ollama mais que le runtime local est arrêté, Elora bloque avant de consommer la queue et propose start_local_runtime. Le cockpit peut alors appeler elora-runtime ensure local_ollama --confirm "START OLLAMA" --json; le contrat générique délègue seulement le démarrage local à l'adaptateur Ollama. Le cockpit peut aussi lire /api/model-selection?task=code pour afficher provider, runtime et modèle sans inférence. Le lancement ciblé passe ensuite par elora-execute run-worker: il exécute uniquement le worker déjà associé à cette mission, puis synchronise le record; il ne consomme pas un autre job global, ne ferme rien, ne mute ni mémoire, ni routing, ni provider.
Capability doctor
Pour une recherche publique, le Workbench lit la capacité effective, pas seulement le nom de l'agent. Il distingue corpus local, inspection d'URL connue et découverte Internet. Le chemin nominal gère SearXNG sur loopback sans systemd et le sonde avant dispatch; strategic_research_agent exécute ensuite le worker local_research, pas Hermes. Si le moteur ne peut pas démarrer, le cockpit affiche public_web_discovery_not_ready avec une action précise ou accepte des URLs fournies. Si un run ne produit aucune preuve d'outil, il affiche runtime_or_input_change_required et retire la relance identique.
Verification
La console Verification appelle elora-verify inspect via POST /api/result/verify. Elle résout une queue ou une exécution vers le fichier résultat, affiche le snapshot stocké dans Result Acceptance, relance l'inspection déterministe et peut utiliser une preuve temporaire fournie par l'opérateur. Elle ne persiste pas cette preuve, n'accepte pas le résultat et ne mute ni mémoire, ni routing, ni provider.
Context files
La console Contexte liste les dossiers Markdown enregistrés, recommande les fichiers par agent/domaine/playbook, prévisualise un pack et permet d'attacher explicitement ces fichiers à un playbook ou à une exécution. Un pack blocked bloque le dispatch sans override explicite. Le cockpit ne les promeut jamais en mémoire: il appelle elora-context-files, elora-playbook et elora-execute.
Harness
La console Harness appelle elora-harness pour lister les scénarios, afficher un scénario, lancer un diagnostic dry-run et écrire une trace proposal-only. Elle vérifie readiness mission: agent, contrat, scénario, playbook, inputs, evidence gate, contexte Markdown, gold reference, artefacts et policy, sans lancer le worker.
Agent Ops
La console Agent Ops appelle /api/agents/actions, qui délègue à elora-agent operational. Elle montre quels agents sont full_e2e_proven, readiness_only_by_policy, encore sans trial, ou bloqués/setup-required, puis affiche des actions sûres: inspecter agent/réalité/contrat, lancer un harness dry-run, relancer un trial readiness-only, inspecter un Mission Pilot ou préparer un Golden Path sans dispatch. Le bouton d'exécution appelle /api/agents/action-run avec agent et action_id; le serveur reconstruit l'argv depuis la matrice Elora et refuse toute commande navigateur, action mutative ou worker dispatch caché.
Capabilities
La console Capabilities inspecte les capability packs, lance validate, affiche doctor et prépare un promotion plan. La prévisualisation est read-only; la génération d'un dossier exige GENERATE CAPABILITY PROMOTION. Elle ne crée pas d'agent actif, ne lance pas de worker et ne mute ni config, ni mémoire, ni routing.
Memory console
La mémoire doit être inspectable et administrable, mais le cockpit ne devient pas propriétaire de la mémoire.
Admin / hygiène
Nettoyage des sessions, queue, exports, logs et workers avec dry-run, preview et approval quand nécessaire.
Playbooks
La console Playbooks liste les procédures domaine, affiche les inputs requis, lance des previews et crée des scaffolds locaux via elora-playbook. Chaque run conserve son snapshot de gate; la création du scaffold ne lance pas automatiquement de worker.
Avatar futur
Une présence visuelle, animée, vocale ou même visio pourra devenir une surface d'interaction d'Elora. Sa mémoire, son routage et son autorité resteront dans le control plane, pas dans l'avatar lui-même.
elora-result artifact, Worker Registry via /api/workers, /api/worker/run, /api/worker/lifecycle, /api/worker/attach et feedback worker proposal-only via /api/worker/feedback, Patch Review local_code via elora-code patch inspect/decide derrière confirmation DECIDE PATCH, Mission Workbench, brief quotidien compact via elora-execute daily-brief, Operator Ritual via elora-strategy ritual, Strategic Daily Board via elora-strategy daily, runbook opérateur via elora-execute loop et Daily Mission Flow via elora-execute daily-flow, Control Plane read-only via eloractl, Readiness Matrix via elora-readiness, Validation Console via scripts/test.sh et /api/validation, Evidence Inspector, Verification via elora-verify, context files, Agent Mission Harness, Agent Ops via /api/agents/actions, /api/agents/action-run et elora-agent operational, Capability Factory via elora-capability, Mission E2E via elora-e2e, Mission Live Run et Mission Operations via elora-live-run, Operator Flow V2, Work Intake, Golden Path Missions via elora-execute golden-paths, Golden Path Runner via elora-execute golden-run, Golden Path Pilot via elora-execute golden-pilots et golden-pilot, Mission Pilots via elora-execute mission-pilots et mission-pilot, Mission libre avec sélecteur mission preset, Mission preflight, Mission readiness et pending mission resolver, Mission Lifecycle Board, Sequence Execution Bridge, Mission Control, Strategic Operating Loop, Execution Handoff, Mission Deliverable Synthesizer via elora-execute synthesize, Mission Delivery Loop via elora-execute deliver, Mission Outcome via elora-execute outcome, Mission Completion via elora-execute completion, Mission Result Flow via elora-execute result-flow, Mission Safe Continuation via elora-execute safe-continue, Mission Supervisor via elora-execute supervise, exploration preview proposal-only via elora-execute explore, dispatch queue, Next Safe Action, Result Acceptance Gate, feedback résultat proposal-only, Redo Orchestrator, Revision Loop, Attempt Ledger, Attempt Comparison, Revision Learning Bridge, Revision Review, pattern scores, learning trends, learning scorecard, promotion candidates, preview/apply explicite derrière PROMOTE LEARNING, review, learning capture, Learning Review Inbox, Improve et les playbooks; le provider, la policy, le routing, la mémoire et l'identité restent dans le control plane.
capture réelle
Un cockpit local, pas une landing page.
La capture montre l'interface actuelle: sessions à gauche, conversation et artefacts au centre, inspection JSON à droite. Cette surface aide à piloter Elora sans posséder son autorité. Elle n'est pas pensée pour satisfaire les standards d'ergonomie grand public ni pour impressionner: c'est un outil opérateur sur mesure, construit pour mes goûts, mes besoins, mes flux de travail, et pour faire exactement ce que j'attends de lui, rien de plus. Son style suit la même logique: sombre, local, dense, inspectable, plus proche d'un monitoring StackX et d'une console opérateur que d'une interface SaaS.
