Questions fréquentes

Non. Elora est un système logiciel et opérationnel qui orchestre des modèles, workers, mémoires et policies. Le projet ne repose pas sur une affirmation de conscience.

Non. La conversation est une surface. Elora est le control plane qui décide comment traiter une demande, quelles preuves injecter, quel worker appeler et comment auditer le résultat.

Le chemin normal doit rester conversationnel. Christophe donne un objectif en langage naturel; Elora produit un plan de mission conversationnel avec route, agent pressenti, livrables, gates et risques, puis attend go. Si le plan n'est pas bon, Christophe ajuste ou annule. Après confirmation, Elora lance la queue et le cockpit sert à inspecter, faire reprendre, accepter, livrer et apprendre. Les messages affichent aussi une carte Mission control: état safe/warning/blocked, action suivante, intention reconnue, agent et actions naturelles possibles. Cette carte aide à comprendre le fil, mais elle ne possède aucune autorité propre. Les consoles avancées restent disponibles, mais elles ne doivent pas devenir la manière obligatoire de penser.

Parce que la mémoire, l'autorité, la continuité et la capacité d'opérer ne doivent pas dépendre d'un fournisseur ou d'une API distante.

La page CLI et binaires donne une carte synthétique des commandes Elora: control plane, missions, mémoire, agents, learning, workers, providers locaux et wrappers historiques. La syntaxe complète reste volontairement dans chaque commande via --help, pour que le site ne devienne pas une source de vérité divergente.

Elora est construite pour moi, mon contexte, mes contraintes et ma cohérence de vie. Ce n'est pas un produit standardisé.

Un modèle local peut répondre, mais il ne fournit pas à lui seul mémoire canonique, routage, audit, policies, artefacts, agents spécialisés et learning loop.

Oui. La route local_code peut produire des artefacts de code dans une session worker locale, utiliser un modèle local OpenAI-compatible pour proposer du code, ou piloter OpenCode comme client de code local. elora-provider select --capability code expose le provider local retenu sans appeler de modèle, puis elora-code backends select rend visible le backend résolu: native, local_model ou opencode. En mode OpenCode edit, Elora peut faire créer ou modifier des fichiers dans le repo, lancer des commandes locales et conserver stdout, stderr, status Git, diff, fichiers changés, result JSON et quality JSON. Les modes read_only, bounded et trusted_free sont explicites, et le Patch Acceptance Gate oblige à inspecter puis accepter, rejeter ou demander une révision du diff. Quand un endpoint local OpenAI-compatible et ELORA_LOCAL_CODE_MODEL sont configurés, ce runtime local est injecté dans OpenCode comme provider elora_local_code. Un modèle plus lourd comme Qwen peut être branché par configuration, mais Elora ne l'auto-lance pas implicitement. Elle ne commit, push, déploie ou mute pas la mémoire implicitement.

local_code est le worker Elora et reste l'autorité d'audit. OpenCode est un backend client spécialisé: il peut aider à comprendre une application depuis zéro, documenter le code, modifier un workspace et lancer des validations locales. Elora l'encadre en analyse read-only par défaut ou en édition bornée explicite, puis conserve les artefacts et le résultat dans la session worker.

Pour tester le câblage Elora, il faut utiliser elora-code doctor, elora-code backends list puis elora-code run --backend opencode. Un opencode run lancé directement peut être utile pour diagnostiquer OpenCode lui-même, mais il ne passe pas par les artefacts, la policy, le provider local forcé et l'audit du worker Elora. En direct, il faut toujours préciser le workspace avec --dir et le modèle avec --model, idéalement dans un repo jetable.

Accepter un patch via elora-code patch decide --decision accepted --apply écrit une décision d'audit dans la session worker. Cela ne fait pas de commit Git, ne promeut rien en mémoire et ne change pas le routing. C'est une étape de revue opérateur: le diff est considéré accepté comme résultat de worker, puis les actions Git ou projet restent explicites.

Non. L'inférence utilise un modèle déjà entraîné pour produire une réponse, un score, une classification ou une extraction à partir du contexte fourni. Elle ne modifie pas durablement la mémoire, la policy ou le comportement d'Elora; les apprentissages passent par proposals, validation et mémoire canonique.

Quand l'espace de réponse est ouvert, stratégique, incertain, créatif, risqué ou qu'une tentative précédente a échoué, Elora peut utiliser un Distributional Exploration Gate puis un Verbalized Exploration Operator. Le but est d'éviter le réflexe de la réponse la plus typique, de produire un candidate set et d'inclure des options moins évidentes mais plausibles. Les scores estimated_typicality ne sont pas des probabilités objectives et ne remplacent jamais preuves, policy, risque, checks déterministes ou validation opérateur.

Il sert quand même plusieurs options restent trop évidentes. Elora génère alors une domain bank de domaines éloignés, puis demande un Semantic Collision Operator de construire des collision candidates avec mécanisme, utilité, risques, preuves nécessaires et checks déterministes. C'est un outil d'exploration proposal-only, pas une preuve, pas une décision et pas une mutation mémoire.

Parce que les modèles tendent à mieux respecter ce qui reste saillant au début et à la fin du contexte. Elora utilise donc un prompt-boundary reinforcement: un contrat final court, auditable et configurable, qui répète seulement les règles Elora-owned. Il ne répète pas le texte utilisateur, les sources brutes, les pages web ou les PDFs. Les commandes, tests, APIs, SQL et procédures validées restent plus autoritaires que l'inférence.

Les agents sont des workers spécialisés. Elora reste l'autorité qui route, borne, audite, juge et conserve la continuité.

Parce que les noms lisibles et futurs codenames servent à l'ergonomie opérateur, pas à l'autorité système. L'agent identity layer peut exposer alias, descriptions et noms reconnaissables, mais le routing, les policies, la queue, les contrats, le learning et l'audit restent attachés aux IDs techniques.

Avec le Worker Reality Gate. elora-agent reality classe le chemin comme deterministic_worker, tool_backed_worker, model_only, stub ou not_ready. La queue conserve le snapshot dans execution.worker_reality. Pour le code local, Elora bloque le dispatch si le chemin ne peut pas réellement produire des artefacts, écrire des fichiers bornés et lancer des tests. Pour StackX prospecting, le chemin nominal est maintenant local_prospect_worker: il produit un dossier local et ne contacte personne.

Non par défaut. Une copie locale de StackX ou un script de qualification peuvent servir de références pour comprendre l'offre, qualifier des sites compatibles ou préparer un worker futur. Cette copie n'est pas le dépôt de développement StackX et ne devient pas une cible modifiable sans route explicite, contrat d'entrée, artefacts attendus, policy et validation opérateur.

Un harness évite de confondre "ça répond" avec "c'est fiable". Il encadre une capacité avec fixtures, entrées représentatives, sorties attendues, critères d'échec et preuves auditables. Dans Elora, il sert à vérifier readiness et qualité sans lancer de mutation implicite.

L'Agent Mission Harness vérifie qu'une mission réelle est prête à être testée: agent activé, contrat excellent, scénario connu, référence gold du même scénario quand elle est requise, playbook prêt, inputs complets, evidence gate non bloquant, pack Markdown non bloqué, artefacts attendus et policy sans side effect. La couverture inclut notamment prospection, analyse de site, support, code local, sécurité, documentation, décision, forecast et analyse documentaire. elora-harness --write écrit seulement des traces learning proposal-only; il ne lance pas le worker et ne promeut rien. Le cockpit peut l'afficher et lancer ce diagnostic via sa console Harness, mais la vérité reste dans le CLI.

Non. elora-trial distingue readiness_only et trial_ready. trial_ready exige un passage elora-e2e réussi. readiness_only signifie que le contrat, le playbook, les inputs, les gates et le harness sont cohérents, mais qu'aucun scénario E2E isolé ne prouve encore l'exécution locale complète. Le coverage status précise ensuite si c'est un gap E2E actionnable ou un chemin readiness-only par policy, par exemple sécurité ou décision. StackX prospecting et support triage sont désormais full E2E-proven via local_prospect_worker et local_support_worker; les chemins sécurité et décision restent readiness-only par policy. Le cockpit Trials affiche cette distinction sans la recalculer côté navigateur.

elora-harness vérifie qu'une mission est prête sans lancer de worker: agent, contrat, playbook, inputs, gates, gold reference et artefacts attendus. elora-e2e va plus loin dans un data root temporaire: il lance le chemin réel mission, dispatch, queue, worker local, result contract, sync, review, learning preview, feedback preview et close readiness. Il sert à prouver qu'un chemin local fonctionne vraiment, sans Telegram, Hermes, Codex ou provider distant. Le cockpit expose désormais ce chemin dans une console E2E, mais délègue toujours au CLI.

elora-e2e prouve les contrats CLI locaux: mission, dispatch, queue, worker, result contract, review et close readiness dans un data root isolé. elora-live-run prouve le chemin opérateur cockpit au-dessus: il démarre un cockpit loopback isolé, extrait son token, vérifie les refus auth/confirmation, appelle les APIs cockpit réelles, lance sxcore run-once, puis sync, review, delivery, feedback, outcome, learning et close avec les confirmations exactes. Les deux restent locaux et n'utilisent ni Telegram, ni Hermes, ni Codex, ni provider distant.

scripts/test.sh lance désormais la suite fast par défaut: syntaxe, bootstrap et smoke déterministe du control plane. Pour un lot ciblé, utiliser --suite runtime, --suite cockpit, --suite execution, --suite agents ou --suite e2e. Le cockpit expose aussi une Validation Console qui liste ces suites, permet un preview ou un lancement whitelisté, puis conserve le run sous ELORA_DATA_DIR/validation/runs avec stdout, stderr, exit code, durée et policy. Telegram reste opt-in et confirmation-gated; full reste réservé aux contrôles lourds. Dans tous les cas, l'autorité reste scripts/test.sh, pas le navigateur.

Mission Operations transforme le rapport live brut en lecture opérateur: ce qu'Elora a compris, quel playbook et quel worker ont été utilisés, quel contexte a été injecté, quels gates ont été traversés, quel état safe, warning ou blocked ressort, quels artefacts existent et quelle prochaine action est recommandée. Le cockpit l'affiche pour guider l'opérateur, mais ne le calcule pas comme autorité; la source reste elora-live-run et les traces CLI/API.

Le domain rubric harness force chaque fixture locale à déclarer quelles rubriques du contrat agent elle couvre. elora-agent eval expose ensuite rubric_coverage: rubriques couvertes, manquantes, inconnues, pourcentage et readiness. Il vérifie aussi la fixture depth et la multi-case fixture coverage des agents critiques. C'est une preuve de couverture de test, pas une promesse que le prochain worker live sera excellent.

Les gold output references donnent des exemples locaux de livrables sérieux pour les agents critiques. elora-agent gold vérifie qu'ils pointent vers des scénarios existants et expose forme attendue, barre qualité, extrait modèle et anti-patterns. Ce sont des références d'évaluation et de cadrage, pas des mutations de contrat ni une preuve qu'un futur worker live sera excellent.

Non. Un agent trace corpus peut suggérer des trace corpus proposals: gates, playbooks, anti-patterns ou exemples gold standard. Ces éléments restent des propositions inspectables. Ils n'augmentent pas le score Agent Excellence, ne mutent pas les contrats et ne changent pas le routing sans promotion explicite.

Le Agent Improvement Workbench relit les traces et les index learning, puis produit un improvement patch. Le patch est dry-run par défaut. Seul --apply, ou le cockpit avec confirmation exacte APPLY IMPROVEMENT, ajoute explicitement et sans doublon des exigences dans l'overlay Agent Excellence configuré. Telegram peut lister, relire, proposer et prévisualiser, mais refuse l'application. La mémoire canonique et le routing ne sont pas mutés.

Une mémoire locale maintenue, sourcée et typée: archive brute, entries canoniques, embedding text séparé, provenance, récence, contradictions, truth modes et miroir Markdown privé.

Elora capture d'abord les sources, maintient des entries canoniques, récupère les preuves utiles, assemble un evidence pack limité, puis l'injecte dans le contexte du provider ou du worker. La réponse ne reçoit pas toute la base, seulement le contexte nécessaire, avec sections facts/assessment/recommendations/hypotheses/unknowns/required_clarifications et rappel que le déterministe prime sur l'inférence.

elora-evidence inspect relit un run playbook, une exécution ou une queue et produit une inspection: présence L0/L1/L2/L3, contrat de réponse, autorité déterministe, issues, warnings, inconnues, recommandations, questions de clarification et context quality gate. Le cockpit expose la même lecture dans l'Evidence Inspector. Pour un simple affichage, ce gate ne mute rien. Au moment du dispatch, elora-execute bloque un contexte blocked sauf raison d'override explicite, puis stocke le snapshot avec l'exécution et la queue.

Mission Control lit les ledgers locaux: daily operating core, attention guard, operator-state, playbooks et readiness agents. Il priorise l'état opérateur et le focus avant les next actions ordinaires, puis propose un handoff déterministe. Il ne lance pas de modèle, n'exécute pas de commande arbitraire et ne mute pas la mémoire.

L'operator-state ledger reste un registre opérationnel local: énergie, fatigue, charge, disponibilité, contraintes et engagements. elora-operator-state context en produit un Operator Context Pack read-only que le board stratégique peut lire pour éviter d'ajouter de la charge quand le contexte est absent, ancien ou risqué. Ce pack est explicitement non médical: il ne diagnostique pas, ne prescrit pas, n'écrit pas Memory V2 et ne décide pas à la place de Christophe.

Oui. Le Strategic Operating Loop appelle elora-strategy, qui enveloppe Mission Control et l'intuition pipeline. Il produit un brief, un triage texte, une proposition de séquence ou une review sans inférence modèle, worker caché, mutation mémoire ou mutation routing. La seule écriture possible est sequence --apply, qui délègue explicitement à elora-intuitions.

Le cap vit dans le ledger local des objectifs stratégiques, créé par elora-objectives. elora-strategy weekly produit ensuite un Strategic Weekly Pack read-only avec objectif principal, risques de dispersion, décisions, open loops, next actions et contexte opérateur. elora-strategy daily lit ce pack pour montrer si l'action du jour est alignée ou si l'objectif doit être converti en next action. Rien de tout cela n'écrit Memory V2, ne lance de worker ou ne décide à la place de Christophe.

Le Strategic Daily Board, exposé par elora-strategy daily, répond à une question de pilotage: qu'est-ce qui mérite mon attention maintenant, pourquoi, et comment stratégie, exécution, attention, contraintes, horizon long terme et cohérence de vie s'alignent ? Il lit les contrats mission existants et propose des next best actions, mais reste read-only. Le Daily Mission Flow, exposé par elora-execute daily-flow, répond ensuite à la question opérationnelle: où en est la mission active, qu'est-ce qui bloque, quelle action CLI existe déjà, et quelles confirmations sont requises ? Le Workbench affiche les deux: stratégie du jour d'abord, flux mission ensuite.

Oui, comme surface. Le panneau Mission du cockpit appelle elora-operate pour afficher brief, triage, next, plan-day et preview de handoff. L'application réelle exige APPLY HANDOFF et ne fait que marquer une next action existante en doing. Le cockpit ne devient pas propriétaire de l'autorité, de la mémoire, du routing ou des providers.

Oui. La console Execution garde l'auto-routing, mais le sélecteur mission preset peut forcer un playbook connu via elora-execute mission --playbook PLAYBOOK_ID. Cela aide quand l'intention est claire, par exemple analyse de site, documentation, code local, support, sécurité, décision ou forecast. Le preset ne contourne pas les inputs requis, Mission readiness, les gates evidence, les confirmations ou l'audit.

Le chemin le plus direct passe par les Mission Pilots. elora-execute mission-pilots --json et la console cockpit Pilots listent les missions standard connues avec readiness, preuve E2E, certification, inputs requis, artefacts attendus, gates qualité et commandes sûres. Cela évite de reformuler une mission libre quand le type est déjà connu. Le pilot ne lance rien tout seul: prepare, dry-run, start, dispatch et pilot readiness repassent par elora-execute golden-run, golden-pilot et les confirmations existantes.

Non. La console Control du cockpit appelle eloractl status --json et eloractl doctor --json pour inspecter l'état autoritatif: process, queue, approvals, mémoire, provider, agent, commandes, fichiers et chemins. Elle est explicitement surface_only: elle ne démarre pas les services, ne dispatche pas de worker, n'écrit pas la mémoire et ne change ni routing, ni provider, ni policy.

La Readiness Matrix appelle elora-readiness matrix --json. Elle agrège les doctors locaux et la queue pour classer control plane, commandes, providers, agents, Agent Excellence, playbooks, harnesses, mission runtime, context files et queue en ready, warning ou blocked. Elle distingue désormais status, local_core_status, operational_core_status et cockpit_direct_status. operational_core_status inclut le daemon/control-plane; cockpit_direct_status répond à la question pratique: puis-je encore travailler via cockpit/CLI sans Telegram et sans daemon long-running actif ? Les fast doctors agents/harness gardent cette lecture rapide, les deep doctors restent disponibles pour audit. Une capacité distante non configurée, un agent désactivé par setup, un playbook optionnel dégradé ou le registre Markdown absent peuvent apparaître en advisory_warnings sans bloquer le chemin local. Le cockpit l'affiche en lecture seule; la CLI reste l'autorité.

Mission V0 Acceptance répond à cette question plus directement que la readiness générale. elora-acceptance check --json vérifie dans une racine isolée le flux opérateur naturel: objectif donné à Elora, plan conversationnel proposal-only, ajustement naturel conservé en mission_control.state=pending_plan sans dispatch, confirmation go, mission queue inspectable, continue borné via superviseur, jugement naturel c'est bon enregistré comme feedback proposal-only, mission readiness, clarification concrète quand une URL manque, Golden Paths et Mission Pilots. Le check rapide ne dépend pas de Telegram, Hermes, Codex, d'un provider distant ou d'un modèle, et ne mute ni mémoire, ni routing, ni provider. Le cockpit expose le même gate dans la console Accept; --include-e2e ajoute seulement sur demande le chemin local E2E plus lent.

Parce que status et operational_core_status peuvent compter l'état du daemon control-plane. En développement manuel, il est normal que ce daemon soit arrêté, surtout si Christophe travaille directement par cockpit/CLI. Dans ce cas, il faut regarder cockpit_direct_status: s'il est ready, le chemin local cockpit/CLI reste praticable, même si le mode daemon complet demande une action séparée. Les sources readiness sont collectées en parallèle avec timeout et exposent source_timings / slow_sources; un doctor lent devient une alerte visible au lieu de bloquer l'interface. Pour tester le chemin pratique, elora-readiness cockpit-direct-smoke --json lance uniquement des probes read-only ou dry-run: fast doctors, mission dry-run, board et loop.

Operator Flow V2 est l'écran de départ du cockpit. Il regroupe l'état Work Intake, Sequence Execution Bridge, Mission Control, Execution Handoff, queue, playbooks, review, learning capture, feedback et Improve pour afficher le travail actif, les readiness importantes et le prochain geste sûr. Il lit les contrats CLI/API existants; il ne lance pas de modèle, n'écrit pas la mémoire, ne change pas le routing et ne remplace pas les confirmations explicites des consoles dédiées.

Le chemin V1 passe par Work Intake / Mission Composer. Le cockpit appelle elora-intuitions pour capturer une intuition locale, puis la transformer en séquence avec étapes, artefacts et critères de succès. Capture et séquence sont dry-run par défaut; l'application réelle exige CAPTURE INTUITION ou CREATE SEQUENCE. Le Sequence Execution Bridge peut ensuite prévisualiser ou créer l'exécution depuis cette séquence avec confirmation EXECUTE SEQUENCE.

Oui. La console Execution contient Mission libre: elle appelle elora-execute mission pour transformer une demande opérateur en next action virtuelle, plan Execution Handoff, start réel et dispatch optionnel. La preview ne mute rien et affiche Mission preflight puis Mission readiness: texte original, texte effectif, hypothèses de composition, statut safe, warning ou blocked, possibilité de start/dispatch, agent primaire, worker reality, artefacts attendus, gates qualité et prochaine action recommandée. Le start exige START MISSION; start + dispatch exige DISPATCH MISSION. Si l'URL, le repo, le ticket ou un autre input requis manque encore après composition, Elora crée une pending mission avec questions concrètes au lieu de lancer une mission floue.

Elora lance le Conversation-to-Execution Bridge. Le chemin prioritaire appelle elora-execute mission --apply --dispatch: si la mission a un playbook et un worker prêts, le tour expose execution_bridge.ok=true, un execution_id, la readiness, le queue_id du worker et une supervision_preview dry-run. Ensuite, Christophe peut répondre continue, poursuis ou fais la suite: le Mission Continuation Bridge applique le superviseur déterministe sur la dernière exécution de la session, sans dispatch ni clôture implicite. Si le chemin n'est pas prêt, Elora ne prétend pas avoir créé une exécution: elle marque fallback_used=true et utilise la queue legacy avec policy/audit existants.

Si la session possède une dernière exécution, le Natural Result Review Bridge mappe ces phrases vers des contrats CLI déterministes. c'est bon devient un feedback accepted proposal-grade. pas au niveau devient un feedback needs_revision et une prévisualisation de révision, sans relancer le worker. rejette enregistre un rejet. prépare la synthèse finale ou livraison finale appellent les chemins déterministes existants. clos la mission reste une preview de clôture. Si aucune exécution n'est liée à la session, Elora demande un execution_id ou une sélection cockpit au lieu de deviner.

Les commandes déterministes restent prioritaires, mais la conversation naturelle ne se limite pas toujours à go, continue ou c'est bon. Le Conversational Intent Classifier permet à Elora de classer un tour court et ambigu en JSON strict: continuation, feedback, révision, synthèse, livraison, clarification, question ou inconnu. Le modèle local, quand il est utilisé, ne décide rien et n'exécute rien. Il propose une classification; Elora vérifie ensuite le contexte, les gates et les contrats CLI existants.

Elora persiste un brouillon pending mission dans execution-handoff/pending-missions, avec texte original, playbook choisi, contexte, inputs manquants, questions, route et readiness. Le cockpit peut afficher ce brouillon, recevoir une réponse, lancer une preview de clarification, puis appliquer ou appliquer+dispatcher seulement avec les confirmations habituelles. La clarification réentre dans elora-execute mission; elle ne modifie pas directement un prompt worker et ne contourne pas les gates.

La lecture quotidienne compacte passe par Daily Mission Flow, généré par elora-execute daily-flow et exposé via /api/execution/daily-flow. Il agrège boucle opérateur, completion, arbitrage qualité, next-safe-action, readiness de réponse finale et phases de mission pour répondre d'abord à: où en est-on, qu'est-ce qui bloque, qu'est-ce qui est sûr ensuite, et quelle commande existe déjà. Le cockpit affiche cette suite dans une zone Action recommandee, avec actions secondaires disponibles; chaque bouton pointe vers un endpoint borné déjà existant, et les actions apply gardent leurs confirmations exactes. Le contrat daily-flow reste read-only: il ne dispatche pas, ne ferme rien, ne mute pas mémoire/routing/provider/policy et ne donne pas d'autorité au cockpit ou au chat.

La console Execution conserve ensuite la Mission Execution Loop, générée par elora-execute loop et exposée via /api/execution/loop. Elle choisit un focus déterministe, l'action bornée à traiter maintenant, une timeline intake -> evidence/context -> dispatch -> résultat/vérification -> acceptance -> learning/closure, un résumé des gates contexte, dispatch, acceptance, contrat résultat et claims, puis un runbook opérateur. elora-execute operator-loop enveloppe ce même état en contrat opérateur: instruction concrète, question de clarification si nécessaire, contrôles naturels comme continue, c'est bon ou pas au niveau, et commande déterministe derrière chaque contrôle. Dans le Workbench, les étapes deviennent actionnables uniquement quand l'action existe déjà dans focus_item.available_actions; le bouton ouvre donc le même chemin /api/execution/board/action que le board. Enfin, le Mission Lifecycle Board, généré par elora-execute board, regroupe les missions à clarifier, les exécutions prêtes à dispatcher, les workers à synchroniser, les résultats à reviewer, les feedback/outcome/learning/clôtures possibles, les blocages et les éléments clos. Le cockpit peut appeler ces actions via /api/execution/board/action, mais les mutations gardent les mêmes confirmations explicites et ne changent ni mémoire, ni routing, ni policy.

Le runbook opérateur transforme l'état mission en procédure courte: action courante, raison, état des gates, champs requis, confirmation exacte, résultat attendu et règles de refresh. Il est produit par le CLI, pas par le navigateur. Il ne crée pas d'action, ne lance pas de modèle, ne dispatche rien et ne contourne aucune confirmation; il rend seulement le prochain geste inspectable et moins ambigu.

Le Guided Mission Runner est le chemin elora-execute cycle. Il ne remplace pas les commandes existantes: il les assemble en un guide lisible pour savoir où en est une mission ou une exécution, quelles questions manquent, quel blocage existe, quelle commande lancer ensuite et quelles mutations sont interdites. Il reste déterministe et proposal-only: pas de modèle, pas de dispatch caché, pas de fermeture automatique, pas de promotion learning, pas de mutation mémoire, routing ou provider.

Le cockpit transmet les derniers messages de la session active à elora-execute mission --context-json. Le Mission preflight peut alors composer une mission effective en réutilisant une cible évidente, par exemple une URL récente pour un playbook d'analyse de site ou un domaine pour une prospection StackX. Cette composition est déterministe, bornée et inspectable: elle expose les inputs manquants avant/après, les hypothèses utilisées et le texte effectif. Elle ne lance pas de worker, ne mute pas la mémoire, ne change pas le routing et ne contourne jamais les gates de readiness, dispatch ou résultat.

La console Execution peut afficher les Golden Path Missions: analyse de site, prospection StackX, analyse documentaire, documentation, code local, forecast, support, sécurité et décision. Ces cartes viennent de elora-execute golden-paths. Elles montrent playbook, trial, statut, agent, inputs, artefacts et gates. Le Golden Path Pilot ajoute le badge de preuve depuis elora-trial/elora-e2e et peut lancer un check readiness-only sans modèle. Le Golden Path Runner ajoute des inputs JSON, une préparation sans mutation, un dry-run du cycle, un start et un dispatch explicites via elora-execute golden-run. Le runner ne remplace pas elora-execute cycle: il le délègue, stocke un snapshot d'audit sur start, et refuse le dispatch direct si le chemin n'est pas ready.

Une mission ready a un chemin déterministe connu: playbook, trial, worker, inputs, artefacts, gates et policy. Une mission certifiée a en plus une preuve de run local complet: elora-trial a stocké un résultat passed avec execution_proven=true. Depuis le 1er juin 2026, sept chemins sont certifiés localement: analyse site, prospection StackX, analyse documentaire, documentation update, code local, forecast et support triage. Un check readiness-only prouve que le contrat est présent, mais pas que la mission complète s'exécute réellement de bout en bout. Le cockpit peut prévisualiser ou lancer cette certification, mais il délègue à elora-execute certify-golden-paths et demande la confirmation CERTIFY GOLDEN PATHS avant de persister les preuves locales.

Le chemin V1 est Execution Handoff. elora-execute planifie la next action, vérifie une route playbook sûre, expose les inputs manquants, attache un evidence pack au plan, crée un record local, démarre un scaffold playbook, puis peut dispatcher explicitement la mission vers l'agent primaire via la queue Elora. sync relit l'état queue, review attache les propositions, learn matérialise les artefacts learning, et la fermeture/feedback restent explicites. Il n'y a ni worker caché, ni modèle appelé en secret, ni action externe automatique.

Non. La carte Next Safe Action affiche une recommandation déterministe calculée par elora-execute next-action: dispatch preview, sync queue, review, vérification des claims, feedback, issue opérateur, learning, révision, clôture ou clarification. C'est un guidage read-only et proposal-only. Le cockpit ne lance pas de worker, ne ferme rien et ne change ni mémoire, ni routing, ni provider sans action explicite de l'opérateur.

La carte Mission Completion, alimentée par elora-execute completion, agrège l'exécution, le Result Acceptance Gate, la synthèse, la livraison finale, le feedback, le Mission Outcome, le learning, la clôture et la Next Safe Action. Elle affiche l'état courant, la sévérité, les blockers, les warnings et la prochaine commande CLI existante. Elle reste read-only: elle ne lance rien, ne ferme rien, ne promeut rien et ne mute ni mémoire, ni routing, ni provider.

Parce qu'un worker peut terminer techniquement sans produire un livrable utilisable. Le Result Acceptance Gate relit l'état queue, le livrable, les artefacts, la qualité et la review disponible. Result Quality Arbitration, via elora-execute arbitrate EXECUTION_ID, ajoute une lecture opérateur unique: safe, warning, blocked ou not_ready, avec les prochaines actions bornées. elora-execute close --outcome done bloque les états not_ready, failed, missing_artifacts, contract_violation ou needs_revision. L'opérateur peut forcer uniquement avec une raison explicite, conservée dans l'audit.

Le Mission Deliverable Synthesizer passe par elora-execute synthesize EXECUTION_ID. Il relit l'exécution, le Result Acceptance Gate, le result contract, la vérification des claims, la review, le feedback, les artefacts et un extrait du résultat pour produire faits, assessment, limites, recommandations, evidence et prochaine action. C'est extractif et déterministe: aucun modèle, aucun worker, aucune mémoire ou queue mutée. La preview est read-only; la sauvegarde écrit synthesis.json et .deliverable_synthesis uniquement après confirmation SAVE SYNTHESIS dans le cockpit. La vraie réponse finale passe ensuite par elora-execute deliver EXECUTION_ID: elle vérifie le delivery gate et expose un Final Operator Answer structuré avec réponse courte, faits, recommandations, artefacts, limites, confiance, prochaine action et chemins d'audit. Le cockpit l'affiche comme carte lisible en priorité, avec Markdown final, JSON et audit disponibles en inspection.

Oui, mais seulement dans un périmètre strict. Le Mission Supervisor est le chemin opérateur: il relit l'exécution, appelle le moteur auto-runner bas niveau, avance seulement les étapes CLI déterministes sûres comme sync, review, synthèse et livraison finale, puis s'arrête au prochain jugement opérateur. Après un go conversationnel réussi, Elora calcule une supervision_preview dry-run; si Christophe répond ensuite continue, le chat applique ce superviseur borné sur la dernière exécution de la session. Le superviseur ne dispatche pas un worker, ne ferme pas l'exécution, ne capture pas le learning, ne demande pas de révision, ne fige pas le Mission Outcome et ne clarifie pas à la place de Christophe sans autorisation explicite. L'application cockpit exige SUPERVISE EXECUTION; la livraison finale exige toujours SAVE DELIVERY et reste bloquée si la synthèse est absente, stale ou si le résultat n'est pas accepté.

Le Mission Outcome est l'issue opérateur persistée après livraison finale et feedback structuré. elora-execute outcome capture décision, limites, statut des gates, artefacts, learning/close posture et prochaine action recommandée dans mission_outcome.json. C'est un snapshot d'audit: il ne remplace pas le Result Acceptance Gate, ne promeut pas le learning, n'écrit pas la mémoire et ne ferme pas l'exécution.

Le Claim Verification Gate utilise elora-verify: extraction des claims, génération de questions ouvertes, vérification uniquement contre des preuves indépendantes fournies, puis cross-check du brouillon. En V1, une affirmation sans preuve devient un warning unverifiable; une contradiction explicite bloque l'acceptation. Le cockpit expose aussi une console Verification et des boutons Claims qui relancent elora-verify inspect sur une queue ou une exécution, avec preuve temporaire optionnelle. Cette preuve n'est pas écrite en mémoire, et le cockpit ne peut pas accepter seul un résultat.

Non. Avant de remettre une queue en pending, la Revision Loop écrit un Attempt Ledger local avec le snapshot terminal: état queue, result acceptance, result contract, artefacts et erreur. Relancer un worker ne doit pas effacer la preuve qui explique pourquoi il fallait le relancer. Ensuite, l'Attempt Comparison peut dire si le résultat courant est encore non terminal, amélioré, régressé ou inchangé.

Non. Quand la comparaison est prête, elora-execute learn --apply peut écrire un item Revision Learning Bridge dans l'index execution_revision_comparison. elora-learning revision-review agrège ensuite ces items en Revision Review pour distinguer améliorations, régressions et révisions inchangées. C'est une proposition de revue: elle aide à repérer les patterns d'échec/correction, mais ne modifie pas mémoire, routing, provider ou contrat agent.

L'Execution Learning Bridge relie le queue_id d'une exécution à elora-learning. elora-execute learn prévisualise ou capture localement les artefacts, index et, si disponible, la comparaison de révision; le cockpit demande CAPTURE LEARNING pour appliquer. Avant ce point, elora-execute outcome peut figer un Mission Outcome pour garder une issue opérateur lisible. Le feedback résultat est structuré: accepted, needs_revision, rejected ou comment, avec note, contexte de résultat et propagation déterministe vers elora-learning feedback quand la queue existe. Ce jugement ne remplace pas le Result Acceptance Gate. Tout reste proposal-only: pas de mutation automatique de mémoire, routing, provider ou contrat agent.

Non. Le feedback accepted signifie seulement que Christophe juge le résultat utile pour le learning et l'issue opérateur. La fermeture done reste contrôlée par le Result Acceptance Gate, le contrat de résultat, la vérification éventuelle des claims, le feedback explicite et les confirmations explicites. C'est volontaire: un signal d'apprentissage ne doit pas devenir un bypass d'acceptation ou de clôture.

La Learning Review Inbox regroupe les propositions issues des index learning: logs, scores, échecs, succès, feedback, propositions mémoire, playbooks et routing. Elle permet de marquer un item comme revu, accepté, rejeté, snoozé ou promu, mais ce statut reste une décision d'inbox. Il ne modifie pas la mémoire canonique, le routing, les providers ou les contrats agents.

Les promotion candidates regroupent les items learning déjà revus ou acceptés pour montrer ce qui pourrait mériter une promotion explicite: playbook, mémoire, routing, compétence ou revue de révision. Le cockpit peut prévisualiser puis appliquer une promotion directe seulement avec PROMOTE LEARNING; le rapport seul n'exécute rien.

Les pattern scores classent les signaux learning répétés: count, statut, qualité, promotions déjà faites, rejets et direct-promotability. Ils aident Christophe à savoir quoi revoir en priorité, mais ils n'écrivent pas la mémoire, ne changent pas le routing et ne promeuvent rien seuls.

Les learning trends suivent les scores qualité et le feedback opérateur par agent et task class. Ils indiquent si un domaine progresse, régresse, manque de feedback ou mérite une revue gold-standard. Ils n'appliquent aucune mutation de routing, mémoire ou contrat agent.

La learning scorecard croise readiness d'excellence, tendances, feedback et pression inbox pour dire quels agents méritent d'abord l'attention opérateur. Elle produit une priorité de revue et des questions utiles. Elle ne donne pas une confiance automatique et ne modifie ni mémoire, ni routing, ni contrat agent, ni provider.

L'agent contract gate relit un run par rapport au contrat de compétence de l'agent: rubrique, artefacts, autorité déterministe, scénario, livrable, quality gate, preuves et sortie inspectable. Il rend les blocages visibles mais ne mute pas le contrat.

PostgreSQL reste le store canonique. En cas d'indisponibilité, Elora peut écrire dans un spool local append-only pour replay ultérieur. Ce fallback n'est pas une seconde mémoire officielle.

Non. Il existe deux usages distincts. Le miroir Markdown est un export privé généré depuis PostgreSQL. Les context files sont des dossiers Markdown vivants sélectionnés explicitement pour une mission, un playbook ou une exécution. Elora peut les recommander, les packer, les gate et les transmettre au worker, mais PostgreSQL reste la mémoire canonique; modifier un Markdown ne modifie pas Memory V2 sans proposition et promotion explicite. Si le pack est blocked, par exemple parce qu'un fichier est archivé ou superseded, le dispatch est refusé sauf override opérateur explicite.

Ollama fournit le runtime local pour certains modèles de chat, de raisonnement, de code et d'embeddings. Il permet à Elora de rester utilisable localement avant d'escalader vers des providers distants quand une route l'autorise. Pour le code local, Ollama ou tout endpoint OpenAI-compatible local peut héberger un modèle dédié plus lourd, par exemple Qwen, tant que le choix reste explicite, auditable et remplaçable.

elora-ollama doctor --json vérifie binaire, API locale, PID stale, modèle et alignement provider. elora-ollama profiles --json montre les profils runtime: Ollama courant, llama.cpp local et futur SSH llama-server. elora-provider runtimes --json --probe indique quels providers sont liés à quels runtimes, pour quelle capacité, et si ce lien est bloquant ou seulement préférentiel. elora-readiness matrix --json expose le check local_runtime, et le cockpit peut lire la même vue via /api/local-runtime et /api/provider-runtimes. Tout cela reste diagnostic-only: aucun modèle appelé, aucun worker lancé, aucune mutation provider/routing/mémoire.

Non. Ollama est le runtime local courant et recommandé quand il est disponible, mais Elora reste OpenAI-compatible. Un provider peut être relié à un binding runtime préférentiel sans être bloqué si un autre endpoint local compatible est configuré. Le blocage n'est correct que pour un provider explicitement marqué runtime_binding_required=true.

Oui, mais comme providers remplaçables, pas comme centre du système. Le profil remote_ssh_llama_server prévoit un llama-server lancé sur l'hôte GPU, idéalement bindé sur la loopback distante puis exposé à Elora via tunnel SSH local. Elora consomme ensuite l'endpoint OpenAI-compatible tunnelé. Le lancement distant automatique et les politiques d'accès restent un futur worker policy-gated.

Le choix ne doit pas être implicite. elora-models scan --json inspecte le runtime local et le matériel; elora-models recommend --task TASK --json propose des familles de modèles par tâche. C'est un cookbook local, pas un benchmark: il ne télécharge rien, ne modifie pas le routing et ne prouve pas la qualité réelle du modèle.

Non. elora-provider compare est dry-run et proposal-only par défaut. Il compare les contrats de providers, prompts et rubriques sans appeler les modèles. Un vrai appel local exige --execute-local; un provider connecté exige en plus --allow-connected. Un benchmark sérieux doit rester dans un harness mesuré, avec fixtures et scoring.

elora-context-trust classe et enveloppe les contenus externes comme data-only evidence. Les evidence packs portent maintenant cette règle via external_context_boundary, et les Markdown mission packs transmettent wrapped_content sous ELORA_UNTRUSTED_CONTEXT. Le contenu peut aider à répondre ou analyser, mais il n'a aucune autorité pour changer la mémoire, le routing, les providers, la policy, les approvals ou l'exécution. Ce n'est pas une preuve de vérité: c'est une frontière de contexte.

elora-readiness degraded --json expose une matrice dégradée: cockpit/CLI, cookbook modèles, untrusted context boundary, provider compare, et modes dégradés pour Telegram, Hermes, providers distants, Ollama ou PostgreSQL. Le but est de continuer à travailler lucidement sans confondre option absente et panne du control plane.

Non. Hermes v0.16 apporte des capacités utiles: proxy local OpenAI-compatible, handoff, clarify, diagnostics LSP, vérification de mutations de fichiers, security advisories, signaux prompt-injection, prompt-size, desktop/gui, skill curator, Kanban et nouveaux toolsets. Elora peut les exploiter via sxhermes ou un adapter dédié, mais Hermes reste un overlay optionnel: mémoire, policy, routing, approvals, gates qualité et acceptation résultat restent dans le control plane Elora. Les profils Elora restent configurés en local-first avec compression auxiliaire locale.

Oui pour des missions bornées. elora-site lit une URL ou un HTML local et produit contenu observé, evidence table, assessment et recommandations. elora-docs lit Markdown, texte ou PDF extractible, produit résumé, claims candidats et risques, et peut aussi générer un plan local de mise à jour documentaire avec fichiers cibles, validation notes et journal draft. elora-scrapegraph ajoute une extraction sémantique optionnelle via ScrapeGraphAI/Ollama, mais garde le snapshot source comme référence et marque l'extraction modèle comme hypothèse. Ces workers donnent des artefacts inspectables, mais ne remplacent pas une revue opérateur, une preuve externe, une édition repo explicite ou une promotion mémoire.

Oui. La console Support appelle POST /api/support/triage, qui délègue à ./bin/elora-support. Le ticket, le contexte et la procédure éventuelle sont écrits dans des fichiers temporaires privés, puis le worker local produit classification, evidence gaps, prochaines actions, rapport et brouillon client avec disclosure IA. C'est un triage draft-only: aucun message envoyé, aucun ticket muté, aucune mémoire canonique écrite, aucun routing ou provider modifié.

La console Workers liste les workers locaux connus via /api/workers, affiche leur readiness et leurs policy boundaries, puis lance les workers queue-compatibles via /api/worker/run. Elle couvre site, docs, code local, forecast, prospection StackX et support. Chaque run direct expose maintenant un lifecycle borné: preflight gate, result contract, quality gate, learning hint, artefacts et feedback opérateur proposal-only via /api/worker/lifecycle et /api/worker/feedback. Les sorties directes sont normalisées: result.json garde le payload natif, ajoute native_result et expose un deliverable validable par elora-result. /api/worker/attach permet ensuite de transformer ce run direct en exécution Elora direct_worker, avec Result Acceptance, synthèse, livraison, feedback, outcome et close, sans relancer le worker. elora-scrapegraph y apparaît comme capacité directe, mais n'est pas lancé par ce endpoint V1. Le registry sert aux lancements opérateur directs; pour une mission complète préparée dès le départ avec evidence packs, dispatch, révision, outcome et learning, le chemin recommandé reste elora-execute.

Non. Un worker direct reste d'abord un run borné du Worker Registry. Christophe peut prévisualiser le pont, puis appliquer l'attachement avec confirmation ATTACH WORKER. Elora crée alors une exécution déterministe exec-worker-QUEUE_ID-RUN_ID qui référence le lifecycle et le résultat normalisé. Cette opération ne mute pas la mémoire, ne change pas le routing, ne promeut pas de learning et ne lance aucun nouveau worker.

Non. ScrapeGraphAI est un enrichisseur local optionnel pour extraire une structure sémantique depuis une page ou un HTML. Elora continue d'utiliser elora-fetch, elora-site, snapshots navigateur, fichiers et preuves déterministes comme base. Le modèle peut aider à organiser le contenu, mais il ne devient pas l'autorité, ne mute pas la mémoire et ne remplace pas la vérification source.

Oui, mais pas comme une intuition magique. La capacité timeseries.forecast appelle localement TimesFM quand il est prêt, ou un fallback déterministe pour les tests. Les résultats sont des hypothèses de forecasting, avec artefacts et limites, pas des faits mémoire ni des décisions automatiques.

Non. La persona est une couche de rendu et de présence. Elle peut adapter le ton, le style, la chaleur ou un futur avatar, mais mémoire, policy, tools, approvals et identité durable restent dans le control plane.

Parce que la confiance ne doit pas être construite sur une tromperie. Les agents de prospection ou support ne se font pas passer pour des humains.

Parce qu'un fait, une préférence, une décision, une hypothèse, une expression artistique et un symbole n'ont pas le même statut ni le même usage.

C'est une trajectoire envisagée: avatar animé, voix, présence visuelle et peut-être visio plus tard. Mais l'avatar restera une surface relationnelle. L'identité d'Elora reste dans le control plane, la mémoire, le routage, l'audit et la continuité.

Parce qu'Elora a besoin d'un espace narratif et technique propre, plus stable qu'un fil de posts, plus vivant qu'une documentation froide.