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.

Oui. Les salutations, questions générales et échanges légers passent par une réponse directe, idéalement rendue par le provider local depuis un evidence pack Elora-owned. Les questions comme "Qu'est-ce qu'Elora ?" injectent un self-model compact pour éviter l'improvisation générique du modèle. Si aucun provider n'est disponible, le fallback local reste explicite. Les accusés courts comme ok ou merci restent de simples réponses locales; ils ne deviennent pas un go d'exécution sans plan de mission en attente.

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 une confirmation naturelle. Les tours courts comme confirmer, ajuster, annuler, demander le statut, continuer ou juger un résultat passent par elora.intent.v1, puis seulement ensuite par les contrats CLI déterministes. 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. Dans le cockpit, l'Action principale Workbench met d'abord une seule action recommandée devant Christophe, puis garde les cartes détaillées dessous. Cette action vient des contrats existants: Mission Result Flow, Supervised Mission Execution, Daily Mission Flow ou loop. Elle montre état, source, raison, commande et confirmation; son clic ouvre une modale guidée pour preview, note, override éventuel et confirmation exacte, puis affiche la dernière action, recharge les contrats et montre la prochaine action sélectionnée. 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.

Une pending mission incomplète peut devenir le focus quotidien. Elora ne doit pas l'ignorer ni inventer le contexte manquant: operator-loop, daily-flow, daily-brief et supervised-flow exposent maintenant les inputs manquants, la question précise, la commande de preview elora-execute clarify ... --dry-run, puis les chemins start ou dispatch avec confirmations exactes. Le blocage devient donc une demande concrète, pas une boucle vague.

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 runtime status --probe --json vérifie le runtime code local sans inférence et elora-code runtime smoke --execute-local --json lance un appel modèle minimal uniquement si l'opérateur le demande. elora-code backends select rend ensuite 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. GLM-5.2 est maintenant le candidat recommandé pour le code agentique local s'il est servi localement; Qwen ou d'autres modèles restent branchables par configuration. Elora ne télécharge pas, ne lance pas et ne promeut pas ce modèle implicitement. Elle ne commit, push, déploie ou mute pas la mémoire implicitement.

Le cockpit lit /api/local-code-runtime, qui délègue à elora-code runtime status et elora-code backends select. Le bouton status lit la configuration sans inférence, le probe vérifie /v1/models sans inférence, et le smoke exige SMOKE LOCAL CODE RUNTIME parce qu'il appelle réellement le modèle local. Si le runtime est dégradé, Elora bloque seulement le backend local_model; les chemins déterministes natifs restent utilisables quand ils sont adaptés.

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.

Par proposition d'abord. elora-capability crée un Capability pack avec agent stub, playbook skeleton, inputs requis, artefacts attendus, quality gates, readiness et promotion checklist. Ce pack est inspectable sous ELORA_DATA_DIR/capability-factory/, mais il ne rend rien opérationnel seul. Le cockpit peut lister, montrer, valider et préparer un dossier depuis sa console Capabilities, toujours en déléguant au CLI. elora-capability promote-plan ID --apply --json ou l'API cockpit avec confirmation GENERATE CAPABILITY PROMOTION génère ensuite un Capability promotion plan: patches candidats pour identité agent, contrat de compétence, playbook, excellence, fixture et harness. Ces fichiers restent reviewables et proposal-only; ils ne modifient pas la config active tant qu'une promotion explicite n'a pas été revue et appliquée.

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. Sept chemins pratiques sont full E2E-proven; treize chemins restent readiness-only par policy, dont les workflows de jugement opérateur et les spécialistes proposition/revue/curation. Le cockpit Trials affiche cette distinction sans la recalculer côté navigateur.

Avec l'Agent Operational Matrix. elora-agent operational --json agrège inventaire agents, Agent Excellence, fixtures eval, couverture elora-trial et Golden Paths. Le cockpit affiche cette information dans Agent Ops via /api/agents/actions, avec des actions sûres par agent: inspection, réalité worker, contrat, harness dry-run, readiness-only trial, Mission Pilot ou Golden Path prepare selon le niveau de preuve. Si Christophe clique sur une action, /api/agents/action-run relit la matrice, retrouve l'action par agent et action_id, valide son argv et ses flags non mutatifs, puis seulement ensuite exécute la CLI déclarée. Cette vue ne lance aucun worker caché et ne modifie ni mémoire, ni routing, ni provider, ni contrat.

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 chemin reste déterministe. elora-strategy review-week --json produit une Strategic Weekly Review read-only: objectifs, next actions liées, décisions, open loops, contexte opérateur et commandes utiles. Si un objectif n'a pas encore de prochaine action explicite, elora-strategy objective-action OBJECTIVE_ID --json prévisualise une Objective Action en dry-run. --apply, ou le bouton cockpit confirmé par CREATE OBJECTIVE ACTION, crée seulement une next-action operator-core avec strategy_objective_id=... dans la note. Aucun modèle, worker, queue, mémoire canonique, routing, provider, policy ou contrat agent n'est muté.

Le Operator Ritual expose elora-strategy ritual --mode start|check|close. Il lit le Strategic Daily Board et la Weekly Review, puis retourne la question utile, l'état safe, warning ou blocked, un plan de cadence et les commandes d'inspection. Le cockpit l'affiche au-dessus du board quotidien pour que l'usage courant ressemble à une discussion avec une associée stratégique: démarrer par le cap, vérifier le focus, clore avec les open loops. Le contrat reste read-only: pas de modèle, pas de worker, pas de queue et pas de mutation mémoire/routing/provider/policy.

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, statut post-go déterministe, safe-continue, jugement naturel c'est bon enregistré comme feedback proposal-only, et readiness de réponse finale via commandes de synthèse/livraison visibles. Il vérifie aussi mission readiness, clarification concrète quand une URL manque, Golden Paths et Mission Pilots. elora-acceptance field --json ajoute une répétition terrain sur plusieurs missions pratiques: analyse de site, code local, support, documentation, forecast, brief de décision et inputs manquants. Le cockpit expose les deux dans la console Accept: Check rapide pour le chemin quotidien, Field rehearsal pour les classes de mission. Les lignes terrain peuvent maintenant ouvrir le Mission Pilot correspondant, afficher ses inputs, puis lancer Preflight, Dry-run, Start ou Dispatch via elora-execute golden-run. Ces checks ne dépendent pas de Telegram, Hermes, Codex, d'un provider distant ou d'un modèle, et ne mutent ni mémoire, ni routing, ni provider. --include-e2e ajoute seulement sur demande le chemin local E2E plus lent.

elora-readiness core-v1 --json agrège trois preuves déjà séparées: matrix, cockpit-direct-smoke et elora-acceptance check. Le résultat donne un verdict opérateur ready, warning ou blocked sur le chemin quotidien cockpit/CLI. Le check reste déterministe et diagnostic-only: aucun modèle appelé, aucun worker dispatché, aucune écriture mémoire, aucune mutation routing/provider/policy. Le mode complet peut prendre quelques minutes. Dans le cockpit, Verifier V1 Core utilise core-v1 --fast: les sous-checks sont bornés et peuvent afficher un timeout visible au lieu de bloquer longtemps. Cette variante est advisory: un timeout de source lente devient un warning avec usable=true, pas un faux blocage du chemin direct. La validation complète reste à lancer en CLI quand on veut un contrôle release.

Non. La construction V1 vise une ligne d'arrivée opératoire: un chemin naturel où Christophe donne un objectif, Elora propose un plan, l'opérateur valide ou corrige, puis la mission avance par contrats CLI avec gates, audit, résultat, feedback, outcome et clôture. Le premier V1 Closure Gate a donné le verdict ready_with_known_limits: le coeur local cockpit/CLI est utilisable pour des missions réelles, mais les limites restent explicites. Les évolutions futures restent possibles; elles doivent corriger une friction concrète, enrichir une capacité utile, ou améliorer un agent, pas maintenir artificiellement une roadmap sans fin.

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.

Le point de départ quotidien est le Mission Workbench. Il affiche d'abord le brief compact elora-execute daily-brief: headline, focus, action recommandée, blockers, warnings et questions de clarification. Ensuite viennent Etat operationnel Elora, l'action principale, le chemin quotidien et les cartes profondes. Le bouton Verifier V1 Core reste explicite et utilise le mode rapide borné; le contrôle complet reste une commande CLI. Le Workbench intègre aussi Mission libre, donc Christophe peut donner un objectif et passer par preview/start/dispatch sans quitter l'écran principal. Le cockpit reste une surface: toutes les actions repassent par les contrats CLI/API et leurs confirmations.

Operator Flow V2 reste l'écran transversal d'inspection. Il regroupe l'état Work Intake, Sequence Execution Bridge, Mission Control, Execution Handoff, queue, playbooks, review, learning capture, feedback et Improve pour afficher les chemins ouverts, les readiness importantes et les diagnostics de flux. 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, Mission readiness, Plan quality gate et Mission auto-resume: 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é, blockers, warnings et prochaine action sûre. 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 et structurées: input manquant, format attendu, exemple et raison. Elle ne lance pas 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 elora-execute safe-continue 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.

Le scénario elora-e2e run daily_mission_conversation_bridge_local --json le teste de bout en bout dans une racine isolée. Il part d'un tour naturel elora-chat, vérifie le plan en attente, confirme par go, crée une exécution lifecycle, dispatche un worker local, relit le statut déterministe, synchronise le résultat, continue par contrat sûr, enregistre un feedback proposal-grade, prépare synthèse et livraison, puis s'arrête sur une preview de clôture. La preuve vérifie aussi l'absence de Telegram, Hermes, Codex, provider distant, inférence modèle, écriture mémoire canonique, mutation routing/provider et autorité cockpit.

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, items de clarification, route, readiness, plan_quality et auto_resume. Chaque item indique quoi répondre, sous quel format, avec un exemple et pourquoi l'information est nécessaire. 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 première lecture quotidienne passe par elora-execute daily-brief, exposé via /api/execution/daily-brief. Il dérive de Daily Mission Flow et donne la réponse compacte: état, headline, focus, prochaine action recommandée, blockers, warnings, questions et commande utile. La lecture détaillée passe ensuite 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. 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. Les deux contrats restent read-only: ils ne dispatchent pas, ne ferment rien, ne mutent pas mémoire/routing/provider/policy et ne donnent 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.

elora-acceptance field --json lance un Field Mission Rehearsal isolé et dry-run-only sur plusieurs classes pratiques: analyse de site, code local, support ticket triage, documentation update, forecast TimesFM, brief de décision avec jugement opérateur requis et cas d'inputs manquants. Le contrôle vérifie inputs structurés, artefacts attendus, quality gates, policy déterministe, disclosure IA quand nécessaire et blocage du dispatch direct sur les missions qui exigent du jugement. Il ne prétend pas que le worker a produit un livrable excellent: il prouve que le démarrage de mission est cadré, inspectable et borné avant lancement réel.

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 Supervised Mission Execution et la carte Next Safe Action affichent une recommandation déterministe calculée par elora-execute: 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.

Le Mission Result Flow, exposé par elora-execute result-flow EXECUTION_ID, consolide completion, arbitrage qualité, synthèse preview, delivery preview, réponse finale et feedback. Il affiche l'état no_result_yet, waiting_worker, needs_review, needs_revision, accepted_needs_synthesis, accepted_needs_final_answer, needs_operator_feedback, needs_outcome, needs_learning ou ready_to_close, avec blockers, warnings, artefacts et prochaine action CLI. Le cockpit le rend comme Resultat mission, mais accepter, reprendre, livrer, apprendre ou clôturer reste soumis aux endpoints et confirmations existants.

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. Mission Safe Continuation est le chemin opérateur quotidien: il relit l'exécution, encapsule 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 elora-execute safe-continue sur la dernière exécution de la session. Ce chemin 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 SAFE CONTINUE; le Mission Supervisor reste disponible comme primitive technique avec 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 GLM-5.2 ou 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, DGX/GB10 local et SSH llama-server. elora-ollama launch-plan --all --json fournit ensuite les commandes opérateur pour démarrer, prober, smoker et brancher ces endpoints, sans les exécuter. 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. Pour le code local, elora-code runtime status --probe --json vérifie aussi que le modèle configuré est listé par /v1/models; elora-code runtime smoke --execute-local --json effectue un appel minimal explicitement local. 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 worker lancé, aucune mutation provider/routing/mémoire, et un smoke réussi ne remplace pas les gates de qualité.

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. Le profil local_dgx_gb10_llama_server couvre le cas d'un hôte local lourd de type DGX/GB10. Dans les deux cas, le runtime activation plan donne les commandes à exécuter; Elora consomme ensuite l'endpoint OpenAI-compatible. Elle ne lance pas implicitement ces runtimes lourds.

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.17 met à jour l'overlay optionnel et son catalogue de skills, avec des capacités utiles comme 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, computer-use et petdex. 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.