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 ajuster, annuler ou répondre go. Après ce go, 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 ensuite répondre continue: le Mission Continuation Bridge applique le superviseur borné 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. Le Conversational Intent Classifier complète ce chemin: il peut utiliser un modèle local pour classer une intention ambiguë, mais seulement en JSON strict, classifier-only, puis Elora repasse par les mêmes contrats déterministes. Chaque réponse peut afficher une carte Mission control avec état safe/warning/blocked, action suivante, intention reconnue, agent et actions naturelles possibles; cette 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 rassemble la mission active, le playbook, l'agent/worker, le context gate, la queue, le Result Acceptance Gate, le feedback, l'outcome, le learning, la timeline de mission, le runbook opérateur, la prochaine action sûre et les actions déclarées par les CLIs. Le runbook vient de elora-execute loop: il indique quoi faire maintenant, pourquoi, si l'action est safe, dry-run, bloquée, à confirmer ou à juger, quels champs sont requis et quel résultat attendre après rafraîchissement. La timeline et le résumé des gates sont actionnables quand une action existe dans focus_item.available_actions: evidence, clarification, dispatch preview, review, learning ou close restent des appels au contrat board. Les actions lifecycle passent par une modale structurée avec métadonnées, champs requis, confirmation exacte et preview dry-run quand un équivalent existe. L'auto-refresh est borné; le navigateur n'invente pas d'action et ne possède pas l'autorité.
Strategic Daily Board
Le Workbench affiche maintenant elora-strategy daily avant le flux mission. 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 pour afficher l'objectif stratégique principal, l'alignement objectif/next-action et les risques de dispersion, puis l'Operator Context Pack pour afficher fraîcheur du check-in, posture, charge, contraintes et prochaine action de contexte sans lancer le brief stratégique complet. Le chemin rapide garde le cockpit réactif; le brief stratégique complet reste accessible séparément par elora-strategy brief --json.
Daily Mission Flow
Le Workbench commence maintenant par elora-execute daily-flow: un contrat compact qui agrège boucle opérateur, completion, arbitrage qualité, next-safe-action, readiness de réponse finale et phases de mission. Le but est quotidien: savoir où en est la mission, ce qui bloque, ce qui est sûr ensuite et quelle commande existe déjà. Le cockpit affiche une zone Action recommandee et des actions secondaires; chaque bouton appelle un endpoint borné déjà existant et les chemins apply gardent leurs confirmations exactes. 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.
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/harness 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.
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, board quotidien, 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.
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 puis Mission readiness: 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é et prochaine action. 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, 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 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 et POST /api/acceptance/check. Elle répond à la question pratique: Christophe peut-il donner un objectif naturel, recevoir un plan, dire go, puis inspecter une mission créée proprement ? Le check rapide crée une racine isolée, vérifie plan conversationnel, go explicite, readiness, clarification utile, Golden Paths et Mission Pilots. Il 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. 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 Supervisor, learning capture, next-action, list, show, close, feedback résultat et Result Quality Arbitration. Le board regroupe pending missions, exécutions, queue, review, result acceptance, feedback, outcome, learning et prochain geste sûr dans des lanes stables. Chaque item 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. 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 supervise avec confirmation SUPERVISE EXECUTION: il avance seulement les étapes CLI déterministes bornées et s'arrête avant tout jugement opérateur. Les cartes affichent 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 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.
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, 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, 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 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.
