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; sinon la queue legacy reste utilisée avec fallback explicite.
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. 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. 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.
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, 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 lit elora-execute: Mission Execution Loop, Mission Lifecycle Board, plan, start, dispatch, sync, review, redo, revision, attempts, compare, synthèse livrable, livraison finale, Mission Outcome, Mission Completion, Mission Result Flow, Mission Safe Continuation, Mission Supervisor, learning capture, next-action, list, show, close, feedback résultat et Result Quality Arbitration. Le board regroupe pending missions actives, exécutions, queue, review, result acceptance, feedback, outcome, learning et prochain geste sûr dans des lanes stables; il expose aussi un historique séparé pour les pending missions résolues ou annulées. Le Workbench rend maintenant cette séparation dans une Mission Inbox filtrable: actives, pending, bloquées, annulées et done. Les cartes annulées affichent la raison et restent inspectables, mais ne reviennent pas dans le focus quotidien. Chaque item actif peut exposer des available_actions déclarées par la CLI; le cockpit les exécute via une modale lifecycle sur /api/execution/board/action, sans inventer de route, sans prompt navigateur opaque et sans bypasser les confirmations. Les pending missions obsolètes peuvent être marquées cancelled par pending-cancel: preview d'abord, raison obligatoire, confirmation CANCEL PENDING MISSION, historique conservé et retrait du focus actif sans suppression. Pour les mutations connues, la modale peut lancer d'abord le dry-run correspondant et afficher le JSON avant application. Les boutons Synthese et Save synthese appellent elora-execute synthesize: ils extraient faits, limites, recommandations, evidence, excerpt et prochaine action depuis les records existants, sans modèle ni mutation mémoire; la sauvegarde exige SAVE SYNTHESIS et écrit seulement synthesis.json plus .deliverable_synthesis. Les boutons Preview delivery et Save delivery appellent elora-execute deliver: ils vérifient que la synthèse est courante, que le résultat est accepté et que les claims/feedback ne bloquent pas; la sauvegarde exige SAVE DELIVERY et écrit seulement delivery.json plus .final_delivery. Les boutons Preview issue et Save issue appellent elora-execute outcome: ils figent la décision opérateur, les limites, gates, artefacts et prochaine action après feedback; la sauvegarde exige SAVE OUTCOME et écrit seulement mission_outcome.json plus .mission_outcome. Continuer mission appelle elora-execute safe-continue avec confirmation SAFE CONTINUE: il avance jusqu'au prochain arrêt sûr, via les étapes CLI déterministes bornées, et s'arrête avant dispatch, close, feedback, learning, révision, clarification ou jugement opérateur. Les cartes affichent maintenant aussi Plan quality gate et Mission auto-resume quand ces contrats existent: qualité du plan, blockers, warnings, action suivante, pending mission, execution id et commande de reprise. Elles affichent aussi le context gate safe, safe_with_warnings ou blocked, le result acceptance après sync/review, le statut claims, l'arbitrage qualité, le dernier jugement opérateur, le Mission Outcome quand il existe, la carte Mission Completion, la carte Mission Result Flow et la carte Next Safe Action. Le feedback peut être accepted, needs_revision, rejected ou comment; il alimente elora-learning feedback en proposal-only quand la queue existe, mais ne remplace jamais le Result Acceptance Gate. Start exige START EXECUTION; dispatch exige DISPATCH EXECUTION et refuse un contexte bloqué sauf raison d'override explicite. Close done refuse un résultat non accepté ou une absence de feedback explicite sauf raison opérateur auditée. Si le résultat est mauvais, le Redo Orchestrator prépare une nouvelle tentative via la Revision Loop, l'Attempt Ledger conserve la tentative terminale, l'Attempt Comparison indique si la suite s'améliore ou régresse, et le Revision Learning Bridge peut transformer cette comparaison en proposition reviewable.
Final Operator Answer
La livraison finale ne se limite plus à un snapshot technique. elora-execute deliver expose .final_delivery.operator_answer: réponse courte, faits, évaluation, recommandations, artefacts, limites, confiance, prochaine action et chemins d'audit. La console Execution rend maintenant cet objet dans une carte dédiée avec badges de gate, bouton de copie, Markdown final et JSON/audit repliés. 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, sync queue, review, claims, feedback, outcome, learning, redo, close ou clarification. C'est une recommandation déterministe et read-only; elle ne lance pas de worker, ne ferme rien, ne mute ni mémoire, ni routing, ni provider.
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.
