Questions fréquentes

Non. Elora distingue le livrable enregistré, la notification à la session et votre satisfaction. Une session neuve peut recevoir directement la réponse d’une mission autorisée. Une notification en échec se reprend séparément, sans refaire le travail ni dupliquer le message. Une session supprimée n’est pas recréée par ce mécanisme. Le rendu persona peut aussi échouer : le document source reste alors disponible et ce repli est inspectable, sans prétendre à une réponse reformulée. Une reformulation complète ne prouve pas à elle seule sa fidélité aux faits et aux citations du livrable.

Pour les missions elora-execute liées à grok_general_agent ou codex_general_agent, les contraintes de périmètre (local uniquement, hors ligne ou exclusion de fournisseur) viennent de l’objectif opérateur accepté, vérifié par empreinte séparément, et non du contenu compilé d’une source. La validation complète de la charge utile reste en vigueur. Sans objectif vérifiable distinct, le traitement est refusé avant la file et le modèle. Les formulations d’une source ne déclenchent plus, sur ce filtre, de fausses restrictions attribuées à l’opérateur ; une source ne peut pas, par ce chemin, lever des interdits réellement imposés. C’est une frontière d’autorisation déterministe sur ce seul chemin, pas une preuve qu’une source ne peut influencer une réponse du modèle ni que tout autre chemin d’exécution serait immunisé. Permissions d’outils, approbation, bac à sable et revue restent nécessaires. Un appel direct non lié elora-agent --mission/--prompt-file est une instruction explicite de l’opérateur ; placez le matériau récupéré dans --context-file.

La commande elora-execute recurring permet de préparer un mandat explicite avec agent, mission, entrées figées, intervalle, échéance et plafond. Le superviseur existant prépare une mission à la fois par mandat ; la file et les contrôles ordinaires restent en charge de l'exécution. Aucun rôle métier n'est activé automatiquement. Un lancement incertain ou un refus opérateur observé bloque les futurs lancements, sans fabriquer de satisfaction. Pause et annulation du mandat concernent les prochaines missions, pas un worker déjà lancé. La qualification utilise un transport simulé ; l'activation réelle exige encore le périmètre opérateur et un watcher chargé avec ce raccordement.

Non. Les essais réels ont trouvé des erreurs de fond malgré des avis favorables. Elora distingue donc l’acceptation technique, le reçu vérifié du critique et la justesse non établie. La proposition peut être livrée, mais sa confiance sémantique n’est pas déduite de la note ; cette réserve reste visible après le rendu persona. Les vrais refus et les preuves manquantes bloquent toujours. Le jugement de Christophe reste distinct, et aucune satisfaction n’est inventée. Ce correctif rend la limite explicite ; il ne qualifie pas à lui seul le raisonnement du modèle.

Elora réutilise sa délégation native. Pour l'architecture et la décision, le coordinateur attend deux contributions complémentaires. Elora garde le mandat, la mémoire, les permissions, les preuves, la reprise et la livraison. Ces équipes travaillent sur les pièces fournies, avec des fichiers autorisés et un calculateur déterministe sans terminal ; un calcul correct ne garantit pas des hypothèses justes. La référence exacte de la source permet une lecture par pages, sans ouvrir les caches ni d’autres fichiers. Les nouvelles exécutions documentaires excluent l'injection automatique des consignes de dépôt et du contexte Git, sans effacer le profil du coordinateur ; les agents de code gardent leur contexte projet. Une trace de lecture ne certifie pas que tout a été compris. Chercher d'autres preuves demande un périmètre adapté. Ce contrôle n'est pas une sandbox OS/réseau, ni une garantie de raisonnement : un résultat techniquement complet peut encore être refusé en revue.

Non. Les nouveaux contrats d'équipe lient les livrables demandés au mandat : absence de fichier, JSON invalide, substitution ou enfant inachevé bloque l'acceptation. Une critique locale confronte aussi les livrables aux sources originales avant livraison ; panne, réponse tronquée ou refus ne valent pas réussite. Les citations et fichiers sont vérifiés par commandes, mais le jugement du modèle reste faillible. Un blocage valide expose ses prérequis ; une critique inexploitable signale un contrôle à rétablir, sans inventer de manque dans le dossier. Les sorties partielles restent inspectables, les corrections suivent le mandat et la satisfaction de Christophe n'est jamais fabriquée pour fermer une mission.

Non. Christophe situe les premiers travaux autour de février 2026. C'est un repère issu de son récit, distinct des premières traces techniques actuellement conservées et de l'annonce publique d'avril. Le journal précise cette chronologie sans inventer de fonctionnalités ou de livraisons pour les mois moins documentés.

Non. Le site est une publication statique : ses jalons datés distinguent contrats livrés, essais isolés, missions réelles et limites. Un résultat de test historique ne certifie pas une autre version, un autre modèle ou une installation actuelle. Le cockpit et les commandes locales donnent l'état opérationnel ; le site public et la passerelle Caddy du cockpit sont deux surfaces différentes.

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 demandes longues ou contextuelles peuvent recevoir une interprétation sémantique locale bornée afin de comprendre l'objectif complet plutôt qu'un fragment lexical ou une poignée de mots-clés. Le modèle ne fait que proposer une route existante: sa confiance doit respecter un contrat strict, et l'enveloppe Elora vérifie ensuite tâche, providers, fallbacks, agents, accès réseau et contraintes explicites comme sans Internet, local uniquement, sans Codex ou sans Hermes. Il n'obtient aucune autorité d'exécution, de mémoire ou de policy, et un fallback déterministe reste disponible. 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.

Non. Une phrase bornée comme Utilise cette source: https://... ajoute la source aux preuves du plan, mais Elora conserve séparément l'objectif qui sert au routing. La recherche ne devient donc pas silencieusement une simple analyse de site. Si le même message ajoute aussi une nouvelle directive matérielle, Elora reroute l'ajustement complet et montre le plan modifié. Dans les deux cas, aucun worker n'est lancé avant un go distinct.

Il reste le seul consommateur de la queue. La conversation suit uniquement le travail attaché à sa mission, puis enchaîne les contrôles, la synthèse et la livraison lorsque le résultat est disponible. L’observation dans le tour est bornée. Sans mandat autonome ou sans superviseur effectif, une tâche longue peut encore nécessiter Continuer mission, et Elora ne promet pas de livraison automatique. Avec un mandat autorisé et un superviseur acceptant du travail, les attentes temporaires sont reprises hors du tour jusqu’au résultat ou à un vrai blocage. Les approvals restent obligatoires ; une attente n’est ni un échec ni une autorisation de les contourner.

Elle ne devine pas. Avant tout dispatch, Elora persiste un identifiant de tentative puis le transporte dans les enregistrements d'exécution et de queue. Un résultat interrompu, partiel ou incohérent devient blocked_apply_outcome_indeterminate: le bouton go disparaît, toute relance ou modification est refusée, et la reprise read-only ne retient que les objets corrélés à cette tentative exacte. Un handoff réussi est lui aussi enregistré avant d'effacer le plan, afin qu'une coupure précédant l'écriture du transcript ne perde pas l'exécution. Un annule explicite bloque seulement la relance conversationnelle, archive la preuve complète sous forme privée et adressée par son contenu, et ne prétend jamais arrêter ou effacer une exécution qui pourrait déjà exister.

Le chemin normal doit rester conversationnel. Christophe donne un objectif en langage naturel; Elora produit un plan de mission conversationnel qui présente l'objectif, trois étapes utiles, le livrable et les limites matérielles, puis attend une confirmation naturelle. La route, l'agent, les identifiants et les contrôles détaillés restent disponibles dans les données inspectables. 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. Au go, Elora conserve l'interprétation présentée sans la redemander au modèle, vérifie l'intégrité du plan, puis revalide la disponibilité et les capacités actuelles : si le type de mission, l'agent, le profil worker ou l'enveloppe de capacité a changé, elle montre le nouveau plan et exige un second accord au lieu de lancer une autre mission sous l'ancien. Un ancien plan valide sans empreinte est d'abord représenté ; un plan altéré est bloqué. Ces contrôles ne certifient pas la qualité de la compréhension initiale. L'application est aussi liée au snapshot exact du worker vérifié en preview et un succès exige la preuve conjointe du dispatch, de l'exécution et de la queue. Après confirmation stable, Elora lance la queue et le cockpit sert à inspecter, faire reprendre, accepter, livrer et apprendre. Les messages gardent une carte inspectable Mission control: état safe/warning/blocked, action suivante, intention reconnue, agent et actions naturelles possibles. Pour laisser la réponse utile dominer, l'intention reconnue est repliée par défaut; un état Mission Control sûr sans action l'est aussi. Un plan, un warning, un blocage ou une action opérateur reste ouvert. 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.

Le contexte en attente aide à comprendre une réponse, mais ne possède pas la conversation. Une précision peut compléter un brouillon à partir de citations vérifiées du texte opérateur, sans autoriser son exécution. Elora mesure les informations réellement acquises ; si le cadrage ne progresse pas, elle conserve la demande et expose le manque restant au lieu de répéter une question générique. Une question ou une salutation ne détruit pas le contexte en attente. Les propositions du modèle restent inspectables et ne valent ni confirmation, ni annulation, ni autorisation de remplacer un plan.

Pas pour une recherche sur une société identifiée : Elora peut préparer une recherche publique couvrant ses activités, produits, services et positionnement, sans inventer son domaine. En revanche, l’audit d’un site précis nécessite une cible web. Un livrable déjà demandé, comme une synthèse, ne doit pas être redemandé ; les exemples cités par Elora ne deviennent pas des cibles fournies par l’opérateur. Le plan et les contrôles de lancement restent distincts du cadrage.

Les commandes explicites gardent leurs chemins déterministes. Une demande libre peut passer par le modèle local, puis par les contrôles de route, de ressources et d’autorité : comprendre un sujet ne crée pas une URL, un fichier ou une permission. Les raccourcis d’inspection exigent une demande complète ; citer une question, parler de mémoire ou refuser une consultation ne doit pas déclencher un rappel personnel. Les reformulations restent interprétables sans catalogue de sujets personnels. Les tests réduisent les régressions, sans garantir la compréhension de toute phrase.

Oui. Une demande d'auto-check appelle le contrat déterministe elora-readiness core-v1 --fast et rend un statut command-backed avec gates, warnings, blockers et provenance. Ce diagnostic est read-only, ne crée pas de mission, ne lance pas de worker et ne dépend pas de Telegram. Le cockpit est la surface primaire; Telegram utilise le même coeur conversationnel comme continuité secondaire.

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. Sur l'hôte principal, GLM-5.3-Flash UD-IQ1_S est désormais le choix local provisoire ; les essais historiques de GLM-4.7-Flash ne qualifient pas automatiquement ce remplacement pour le code. GLM-5.2 reste un candidat frontier de 753B paramètres pour un runtime distribué ou beaucoup plus important. Elora 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.

Le 6 septembre 2026, un essai réel via Elora, OpenCode 1.18.29 et GLM-4.7-Flash local a créé puis corrigé un petit script Bash : 9 tests sur 10 au premier passage, puis 10 sur 10 après une révision, avec syntaxe et ShellCheck validés indépendamment. Le modèle pouvait écrire seulement ce fichier, sans exécuter les tests. Le client était installé temporairement : cette preuve ne vaut ni activation globale, ni benchmark général de qualité. Le défaut de détection des fichiers non suivis révélé par cet essai a ensuite été corrigé et testé indépendamment : le wrapper compare maintenant contenu, type et permissions, avec refus si l’observation est indisponible.

Non. L’installation durable qualifiée le 6 septembre utilise OpenCode 1.18.29 dans un répertoire utilisateur versionné et un profil GLM séparé. Le 7 septembre, le chemin du binaire est ensuite déclaré explicitement dans la configuration privée du cœur permanent, sans ajout au PATH global. La génération ordinaire reste inchangée ; la règle existante d’analyse automatique peut désormais choisir OpenCode disponible. Une proposition isolée requiert toujours le mode explicite, le mandat, les tests et l’accord réseau : installer ou rendre le client disponible ne lui donne aucune autorité de déploiement.

Le mode scopé proposal, accessible par elora-execute mission --local-improvement-contract, exige une validation indépendante avant livraison technique. Les commandes et points d’entrée des tests de référence restent hors du périmètre éditable. Le modèle modifie seulement les fichiers permis ; Elora construit le patch et les rapports, puis exécute les tests. Une révision reçoit le patch refusé et les erreurs comme données, sans modifier le mandat, les tests ou les autorisations. Le worker prépare un candidat isolé ; il ne l’applique pas au dépôt source.

Le 7 septembre 2026, un essai isolé passe Bash, ShellCheck et dix cas avec GLM via OpenCode, après un refus initial pour outils hors policy. Une reproduction distincte sous le superviseur permanent échoue ensuite : 4/10, puis 9/10 et 9/10 après deux corrections explicitement demandées. Elora refuse la livraison et arrête pour stagnation. Ces deux preuves restent conservées : exécution sans client ouvert ne garantit pas qualité, et une réussite passée ne dispense jamais de tester la proposition suivante.

Local ne veut pas dire sans frontière : OpenCode doit joindre le serveur du modèle. Pour le mode proposal, l’adaptateur natif actuel filtre par hôte, pas par port. Le contrat optionnel loopback_host_all_ports autorise explicitement l’hôte loopback sélectionné, y compris ses autres ports ; ce n’est pas une autorisation limitée à Ollama. Sans acceptation de ce périmètre, le plan reste bloqué. Les outils shell et web du client sont interdits et les tests indépendants gardent le réseau fermé. Ce mode dépend actuellement de la CLI Codex comme utilitaire local d’isolation, pas d’un compte ou modèle OpenAI. Le blocage AppArmor est levé sur l’hôte de qualification depuis le 7 septembre ; cela ne donne aucune autorisation réseau implicite.

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 contrôle le contrat, le playbook, les inputs, les gates et le harness sans fournir de preuve d'exécution dans ce run. Le coverage status précise ensuite si c'est un gap E2E actionnable ou un chemin readiness-only par policy. mapped_full_e2e signifie seulement qu'un scénario E2E est configuré ; l'ancien compteur full_e2e_proven_count reste un alias de compatibilité, pas une preuve. Un run historique réussi ne qualifie pas automatiquement les sources ou le modèle actuels. Recherche publique source-gated, workflows de jugement opérateur et spécialistes proposition/revue/curation conservent leurs limites propres. Le worker local rend cette recherche exécutable, mais ne prouve pas à lui seul la fraîcheur ni la qualité de chaque corpus. 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.

Elora capture d'abord l'attempt qui vient d'échouer, crée une demande de correction à partir de la source canonique de la mission et des contrôles qualité précis, puis relance uniquement la queue attachée. Le bouton reste occupé pendant l'action et une requête répétée rejoint la reprise existante sans en créer une autre. Le nouveau résultat reçoit un run_id distinct et une nouvelle review: une note ancienne ne peut plus être réutilisée. Si le livrable échoue encore, le cockpit remplace le choix précédent par le jugement courant et indique la tentative ainsi que l'évolution du score. Après plusieurs reprises sans amélioration, il recommande l'inspection plutôt qu'une boucle identique. Cette reprise n'accepte rien, ne clôture rien et ne modifie ni mémoire, ni routing, ni provider.

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é.

Oui, comme corpus sourcé, pas comme portrait définitif. L'import local conserve l'expression datée et distingue textes propres, réponses, retweets, citations et notes longues. Il exclut messages privés, Grok, contacts, données techniques, fichiers médias et catégories sans publication publique établie, notamment les articles. Une réponse peut manquer de contexte ; un retweet ne prouve ni l'adhésion ni le style de la personne qui le relaie. Les textes propres peuvent servir d'exemples pour une demande de rédaction, mais l'import ne produit pas automatiquement un profil de style, n'entraîne aucun modèle et ne transforme pas les anciens avis en faits actuels. Les synthèses restent révisables, les brouillons soumis à validation humaine et aucune publication n'est autorisée par cet import.

Elora fournit un contexte limité et sourcé, pas toute sa base. Le rappel part du sujet cité et validé dans la demande, sinon de la question complète, sans menu biographique prédéfini. La recherche locale lexicale ou hybride aide à trouver des passages ; ses scores ne prouvent pas leur pertinence. Archives, faits canoniques et hypothèses conservent leurs distinctions et leurs dates. La persona donne la voix, pas les faits à affirmer. Un rappel peut citer naturellement « extrait exact » [memory:M1] : l’identifiant et l’extrait sont vérifiés sur l’élément réellement transmis. Cela prouve l’attribution, pas la justesse de l’interprétation ni son actualité. Une synthèse sans citation reste non vérifiée ; des sources non pertinentes autorisent à le dire plutôt qu’à inventer une biographie. Ce contrôle ne modifie pas la mémoire et ne garantit pas la qualité de tous les rappels.

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.

Le point d'entrée opérateur est elora-operate status: il répond à "puis-je utiliser Elora maintenant ?" en agrégeant readiness V1, cockpit, queue, reprise running en dry-run, board d'exécution, runtime local et ledger opérateur. Il sépare next_action immédiate et recovery_actions pour la dette historique, sans lancer de worker ni muter queue, mémoire, routing, provider ou policy. Pour le diagnostic détaillé, 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 n'appelle aucun modèle. En mode complet, l'acceptance peut exécuter un worker de test dans son répertoire isolé; elle ne dispatche pas de mission dans l'instance opérateur et ne modifie ni mémoire canonique, ni routing, ni providers, ni 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.

Un daemon sain mais arrêté est un warning, pas à lui seul un blocage du chemin quotidien. En revanche, un échec du doctor, du statut ou de la preuve d'identité du core reste bloquant. Pour distinguer les périmètres, 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 Mission Workbench. Il présente la mission liée à la conversation, l’action principale, les missions en cours et Mission libre, sans attendre les diagnostics. Ouvrir Détails avancés Workbench charge la readiness, la stratégie et les flux détaillés ; « non chargé » ne signifie jamais « prêt ». Les rafraîchissements conservent les messages inchangés et les brouillons. Les actions attendent des contrats relus et gardent leurs confirmations CLI/API ; Verifier V1 Core reste explicite.

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 vérifie le plan, la route, les inputs, la readiness et les autorisations avant de créer l’exécution et sa queue. Par défaut, le go confirme aussi un mandat de poursuite lié exactement à cette mission et à sa session : elora-execute mission --apply --dispatch --autonomous. Le même tour avance les étapes sûres pendant une durée bornée. Ensuite, si le superviseur local est actif et armé, il reprend vérification, corrections autorisées, synthèse et livraison sans exiger un nouveau continue. Si le superviseur n’est pas disponible, Elora le dit : un mandat enregistré ne prouve pas un service actif. Un vrai blocage ou jugement opérateur reste explicite. Une erreur de lancement ne déclenche ni queue de secours cachée ni nouvelle autorité. Le mode manuel reste disponible ; les anciennes missions ne deviennent pas autonomes rétroactivement.

Oui si cette mission possède un mandat de poursuite et si eloractl stack watch-status --json confirme que le superviseur accepte du travail. La responsabilité est enregistrée localement, pas dans l’onglet. Le superviseur réutilise le cœur de queue existant ; il n’en crée pas un second. Une réponse finale acceptée est ajoutée une seule fois dans la session d’origine. Un redémarrage retrouve le mandat, mais une opération interrompue dont les effets sont incertains exige une inspection. Une exception étroite concerne la critique seule : si l'identité de la phase, les preuves et la fin des anciens processus sont vérifiées, Elora peut réconcilier un avis déjà valide sans rappeler le modèle, ou reprendre un avis inexploitable dans le budget restant. Elle ne rejoue pas le worker. Un ancien boot prouve la disparition des processus, pas la réussite de la mission.

Le 7 septembre 2026, le superviseur permanent est actif sur l’hôte de qualification. Après les corrections et des essais refusés conservés dans l’audit, une mission réelle Astra/ultra prépare un patch isolé, passe les tests indépendants et livre la proposition après le retour du client initiateur. La récupération du superviseur après une panne ciblée a été observée séparément, sans arrêt du cœur ; cela ne prouve pas encore la survie d’une génération productive à une panne ni un redémarrage physique complet.

Non. Les limites de chargement, d'appel modèle, de critique, de rendu et de supervision bornent des phases distinctes, pas la durée totale d'une mission autorisée. Les valeurs effectives liées au mandat sont revérifiées : elles ne s'agrandissent pas silencieusement après une panne. Une attente temporaire ne met pas fin à la responsabilité, mais le périmètre, les approvals, les plafonds de correction et les contrôles de résultat restent contraignants. technical_completed indique une livraison techniquement acceptée, pas l’avis de Christophe. Le feedback, la promotion mémoire et la clôture opérateur ne sont jamais fabriqués. autonomy pause et autonomy cancel suspendent ou abandonnent la poursuite ; ils ne tuent pas un worker et n’annulent pas une action déjà en file.

Un budget de qualification est un plafond d’essais défini pour une expérience, pas nécessairement un quota de compte, de crédits ou de modèle. Une autorisation de poursuivre peut permettre une nouvelle phase bornée après diagnostic. Les anciens échecs et leurs limites restent visibles : les compteurs ne sont pas remis à zéro silencieusement pour simuler une mission réussie.

Pas nécessairement : ce statut peut décrire la fin d’un appel borné, alors qu’un mandat persistant prévoit la suite. L’état actuel du mandat fait foi, pas une ancienne promesse dans la conversation. Un mandat blocked ne progresse plus : Elora doit expliquer le blocage dans la session liée. Une correction déjà engagée peut encore terminer ; son état observé reste distinct du blocage de supervision et ne prouve jamais une livraison acceptée. Une reprise ne contourne ni les contrôles d’identité de mission ni les autorisations.

Le chemin sxcodex improve, accessible par l’agent existant repo_surgery_agent, prépare une proposition dans un workspace isolé à partir d’un contrat explicite : mandat, fichiers autorisés, validations et budget. Le résultat comprend le patch, les empreintes et les preuves de commandes, pas une simple affirmation du modèle. Ce chemin dépend du profil, de l’authentification et du bac à sable de la machine ; des tests simulés ne prouvent pas un appel réel. Le 7 septembre 2026, ce parcours est qualifié avec Astra/ultra sur une correction réelle et bornée des métadonnées d’Elora, jusqu’à l’acceptation et à la livraison dans la session. La proposition n’est ni appliquée, ni publiée, ni déployée automatiquement sur l’instance active. L’Improvement Workbench historique, lui, produit des propositions de contrats d’agents : ce n’est pas un déployeur de code.

Non. Une exécution créée depuis le dialogue conserve désormais un session_id et un conversation_binding. Quand une session est active, le cockpit récupère son dernier execution_id dans le transcript et appelle elora-execute loop --focus EXECUTION_ID. Le Workbench affiche ce scope et refuse une action qui viserait une autre exécution. Les priorités globales restent consultables quand aucune session n'est ouverte ou depuis la console Execution dédiée; elles ne peuvent plus contaminer silencieusement la conversation visible.

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 inspectable; si elle implique de confirmer, annuler, ajuster, poursuivre, synthétiser ou livrer, Elora conserve l'état courant et demande un contrôle déterministe explicite. Une erreur, un timeout ou une confiance insuffisante ne supprime jamais un plan en attente.

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, recherche web, 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 distingue le parcours configuré du dernier résultat historique issu de 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. Le jalon du 1er juin 2026 documente sept chemins certifiés dans ces conditions : analyse site, prospection StackX, analyse documentaire, documentation update, code local, forecast et support triage. Il s'agit d'un historique, pas d'une certification perpétuelle. Le contrat distingue maintenant proof_scope=historical_run de current_source_qualification=unverified : relire une ancienne preuve ne reteste pas les sources actuelles. Les chemins recherche publique, sécurité et décision restent soumis au jugement et aux preuves propres à la mission. La recherche dispose maintenant d'un worker local et d'un SearXNG géré, mais une fixture locale ne prouve ni la fraîcheur ni la qualité de chaque corpus public; sa certification reste donc liée à la preuve du run. 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.

Le navigateur n'invente jamais une action. En revanche, après un go explicite sur un plan prêt, le control plane peut appliquer automatiquement la suite sûre déjà définie par elora-execute safe-continue: lancer uniquement le worker ciblé, synchroniser sa queue, contrôler le résultat, effectuer des corrections bornées, synthétiser et livrer. Il s'arrête au premier jugement opérateur réel, blocage de sécurité, capacité manquante ou plafond de convergence. Le cockpit reste une surface: mémoire, routing, providers, policy et autorité restent dans Elora.

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. Son coeur déterministe relit l'exécution, les gates, la review et les artefacts, puis choisit l'artefact métier principal au lieu du simple reçu worker. La preview reste extractive et read-only. Sur sauvegarde, un provider local peut rendre cette preuve bornée en français naturel; le provider et le modèle sont tracés, le contenu externe reste traité comme donnée non fiable et le fallback extractif reste disponible si le runtime est absent. elora-execute deliver vérifie ensuite le delivery gate et expose un Final Operator Answer: le contenu demandé apparaît d'abord, les limites utiles et l'artefact principal ensuite, tandis que le JSON conserve le détail complet des gates, fichiers et chemins d'audit.

Oui. Après confirmation d'un plan prêt, la Mission Safe Continuation est appliquée par défaut. Elle ne concerne que l'exécution et la queue ciblées: démarrage du worker prévu, runtime local, sync, review, synthèse et livraison finale. Une review insuffisante peut déclencher une Bounded Quality Convergence sur la même queue, avec trois révisions totales par défaut et arrêt anticipé en cas de stagnation. Un Operator Judgment Contract pose alors une question concrète avec preuves, recommandation et choix. Le mode preview-only reste disponible explicitement. Ce chemin ne lance aucun worker arbitraire, ne clôture pas la mission, ne capture pas le learning et ne mute ni mémoire, ni routing, ni provider.

Oui, lorsque des sources publiques accessibles permettent de l’identifier. Le chemin nominal est local-first : elora-searxng gère un moteur SearXNG loopback ; strategic_research_agent délègue à local_research, qui cherche, récupère un corpus borné, qualifie les sources et produit les artefacts de preuve. repo_corpus_rg reste réservé aux fichiers locaux. Les URLs déjà connues sont lues indépendamment de la disponibilité du moteur ; la découverte peut utiliser les alternatives configurées. Si les preuves restent insuffisantes, Elora distingue panne temporaire avec reprise autorisée et manque nécessitant une précision ou des sources. Les connaissances d’un modèle ne sont jamais présentées comme une recherche sourcée, et Hermes reste un enrichissement optionnel.

Oui. Un modèle local critique le brouillon selon six critères, avec des notes sur 100 et un seuil de 80 par défaut. Elora recalcule le score et conserve les contrôles de sources, citations et affirmations. Pour une analyse d’entreprise, les affirmations chiffrées ou contractuelles font aussi l’objet d’une revue liée aux passages des sources effectivement citées. Elora vérifie ces liens ; préserver le sujet, la période et la portée reste un jugement du modèle, pas une garantie d’infaillibilité. Une erreur de notation ou de format permet au plus une nouvelle critique du même brouillon ; un protocole toujours invalide échoue. Un défaut du document permet jusqu’à deux révisions par défaut. Une indisponibilité initiale du modèle peut laisser un résultat déterministe explicitement dégradé, mais une panne après rejet ne réhabilite jamais le brouillon refusé. Ni une bonne note ni un manque de preuves ne suffisent à déclarer la mission réussie. Christophe conserve le jugement final sur l’utilité réelle.

Le contrôle est commun, mais les preuves attendues diffèrent. Une citation du sujet guide la découverte ; une analyse d’entreprise n’utilise pas automatiquement des requêtes scientifiques. Une URL fournie peut être lue même si la recherche est indisponible. À partir des preuves et des lacunes constatées, un modèle local peut proposer des recherches complémentaires ou des liens réellement observés ; Elora valide et exécute ces propositions dans un budget borné. Une page doit traiter le sujet dans son contenu, pas seulement dans son titre. Les homonymes confirmés demandent une précision ; les déclarations d’entreprise restent attribuées, sans devenir une preuve indépendante de qualité. Les tests sur plusieurs sujets réduisent les régressions, sans garantir la couverture de tout le web.

Elle conserve les résultats utilisables, essaie les alternatives configurées et peut poursuivre depuis les sources déjà connues. Si une panne temporaire empêche réellement d’aboutir, la mission autorisée peut attendre puis reprendre automatiquement, avec une échéance persistée et les limites du mandat initial. L’annulation empêche les futurs départs ; ni une attente ni un résultat insuffisant ne valent réussite. Elora ne prétend pas savoir résoudre tous les CAPTCHA : son navigateur de recherche automatique reste non qualifié tant que l’isolation et le contrôle de chaque requête ne sont pas vérifiés. Aucun service payant ni profil Hermes dormant n’est activé silencieusement.

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. Si elora-execute start --apply retrouve un démarrage déjà entièrement enregistré pour la même action, il renvoie l'exécution existante avec idempotent_replay:true, même si elle est done. Son état et ses preuves restent inchangés : aucun nouveau worker, aucune réouverture ni nouvelle paire exécution/playbook. Une action déjà terminée sans démarrage enregistré reste refusée. Réessayer une commande dont on a perdu la réponse ne doit pas être confondu avec demander une nouvelle exécution.

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 sur l'hôte Elora dédié. PostgreSQL 17 et pgvector utilisent les paquets natifs PGDG ARM64, mais le cluster privé appartient à l'opérateur Elora et son cycle de vie passe par elora-postgres. Il écoute seulement sur la loopback et utilise un socket Unix privé. Les containers restent une exception explicite pour un composant qui ne disposerait pas d'une voie Spark native propre et stable.

Le cockpit reste lié à 127.0.0.1:8765. Sur le Spark dédié, elora-gateway pilote Caddy comme processus utilisateur natif et expose seulement https://elora.home.arpa:8443/ sur le LAN. L'installation courante utilise le port non privilégié 8443, qui doit donc rester explicite dans cette URL; le CLI permet d'en choisir un autre avec setup --port PORT. Le DNS local ou le fichier hosts de chaque appareil opérateur doit faire pointer elora.home.arpa vers l'adresse LAN configurée. elora-gateway doctor prouve le service Caddy/TLS/auth/backend par un probe direct et sépare les observations DNS du serveur, le fallback IP et le chemin externe. Le resolver du serveur ne peut ni valider ni invalider le fichier hosts d'un autre appareil: ce chemin client reste explicitement unverified jusqu'à un test effectué depuis ce client. Le mode par défaut demande le mot de passe opérateur généré dans l'invite native du navigateur; l'avertissement du certificat local peut être accepté, ou la CA locale importée pour le supprimer. Le TLS mutuel avec certificat client reste un mode plus strict optionnel. Caddy remplace les headers internes, puis le cockpit vérifie encore le pair loopback, le secret de passerelle, le Host, l'Origin et son propre token API. Les logs Caddy filtrent ces secrets et le token d'ouverture avant encodage; la lecture CLI resanitarise aussi les anciens formats. La configuration désactive aussi l'autosave Caddy après adaptation, car il pourrait contenir le secret interne résolu depuis l'environnement. sanitize-caddy-autosave inventorie puis nettoie atomiquement uniquement un autosave dont l'appartenance à Elora est prouvée; une configuration étrangère, ambiguë ou liée par symlink est refusée et préservée. Une preuve privée liée au PID, à la version de policy et au hash du Caddyfile confirme séparément que le processus courant a chargé la protection: nettoyer l'autosave ne suffit donc pas à rendre un ancien runtime prêt. Tant que l'artefact reste dangereux ou que cette preuve manque, service_ready peut confirmer le transport mais security_ready et la readiness globale restent bloqués; un redémarrage sûr recharge la policy, tandis qu'un blocker non remplaçable est détecté avant toute coupure. elora-gateway sanitize-logs prévisualise la réparation historique, et rotate-internal-secret prévisualise la rotation du seul secret passerelle-cockpit; --apply reste explicite, verrouillé et audité, sans changer le mot de passe opérateur ni la CA. Aucun accès direct à PostgreSQL, Ollama, aux providers ou au port cockpit n'est ouvert. Cette passerelle est une surface remplaçable, sans Docker ni dépendance obligatoire à systemd, pas une nouvelle autorité.

Le mode historique demandait un démarrage manuel de la stack complète, Caddy compris. Sur un hôte dédié, elora-host-stack.service peut désormais la relancer par les mêmes commandes Elora. Il faut que cette unité utilisateur soit activée et que Linger=yes permette au gestionnaire utilisateur de démarrer sans session interactive. eloractl stack boot-status --json vérifie la configuration et peut observer un démarrage effectif pendant le boot courant en recoupant le noyau, l’invocation systemd et son journal. Cette observation reste distincte de la preuve d’un démarrage avant toute connexion interactive. Une ancienne unité active (exited) doit être migrée puis activée explicitement pour utiliser le nouveau superviseur foreground. Les états de chaque composant restent contrôlés séparément : active (exited) pour l’adaptateur ne suffit pas à prouver que le web répond.

Sur l’hôte de qualification, cette migration est effectuée le 7 septembre 2026 ; l’unité est active et sa reprise après une panne ciblée est observée. Aucun reboot physique n’a été effectué pour ce lot : la preuve de démarrage avant connexion reste à établir.

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 peut servir les modèles de dialogue, de raisonnement, de code et d'embeddings. Les providers peuvent aussi utiliser vLLM ou llama.cpp : les modèles restent des workers remplaçables, pas l'identité d'Elora. Les alias et endpoints effectifs viennent de la configuration locale inspectable, pas d'une affirmation d'état en direct sur ce site. Changer le modèle conversationnel ne change pas implicitement le modèle d'embeddings et demande sa propre qualification.

Pas entièrement résident : les plus petits poids Unsloth du modèle complet occupent 217 Go, hors mémoire de travail, contre 128 Go de mémoire unifiée sur cet hôte. Mais charger les experts à la demande depuis le disque est possible expérimentalement : l’auteur de vllm.cpp rapporte sur GB10 une génération de quatre tokens avec réutilisation du cache, en placement hybride CPU/GPU. Ce n’est ni un débit soutenu qualifié ni une validation de qualité générale ; les durées incluent le chargement et les mesures de processus ne prouvent pas la consommation totale de mémoire unifiée. Cette voie n’est pas qualifiée dans Elora.

GLM-5.3-Flash est un autre modèle. Un essai local isolé du 7 septembre 2026, avec sa quantification de 93,1 Go, passe quatre contrôles de protocole puis produit via OpenCode un script validé par Bash, ShellCheck et dix cas indépendants. Le serveur temporaire est ensuite arrêté ; cela ne change pas le modèle actif et ne prouve pas une qualité générale. Le modèle complet reste non testé ici. L’API distante demande des autorisations et une confidentialité explicites ; un endpoint local qui relaie vers le cloud ne rend pas l’inférence locale.

Non. OpenRouter confirme qu’Ox Alpha était le nom de la préversion anonyme de GLM-5.3-Flash. Les performances annoncées par l’éditeur ne garantissent pas celles d’une quantification locale : Elora distingue identité du modèle, compatibilité du moteur, qualité mesurée et autorisation d’activation.

Non. Il faut aussi maîtriser contexte, quota de réflexion, continuité des fichiers et validation indépendante. Le test multi-fichiers du 7 septembre avec GLM-5.3-Flash montre que prolonger le délai seul ne suffit pas. Un quota de réflexion et des limites de contexte/sortie déclarées au client permettent ensuite de compacter puis reprendre. La première proposition complète atteint 85/86 contrôles ; huit contrôles CLI supplémentaires en révèlent quatre en échec. Une correction GLM, sans réécriture humaine ni modification des tests initiaux, atteint finalement 86/86 et 8/8. Elle prend environ 1 h 31 et trois compactions. C’est une preuve de correction multi-fichiers dans ce banc, pas une garantie de qualité générale ou de rapidité. Les ajustements expérimentaux ne sont ni une activation ni un correctif de production. La mémoire, les permissions et l’acceptation restent sous le contrôle d’Elora.

Des correctifs distincts sont implémentés et testés dans le dépôt de développement : limites contexte/sortie scellées au GO, arrêt des descendants vérifié avant les empreintes, et refus d’autorité séparés des défauts de qualité révisables. Une précédente vérification native isolée d’OpenCode 1.18.29, sans réseau ni appel modèle, confirmait alors la configuration Elora de 32 768 tokens de contexte, 8 192 de sortie et compaction automatique malgré un fichier projet contradictoire protégé en lecture seule. Cela prouve la configuration effective, pas une nouvelle compaction ou une nouvelle génération.

À cette date, le profil permanent GLM-4.7 n’avait pas été modifié : ses limites inconnues bloquaient ce mode de proposition. Les régressions ciblées de mission, correction et livraison passent avec des workers inertes. Ces tests n’attestaient ni Flash en production, ni une activation ou un déploiement, ni la publication du site. Les réglages actuels de la station sont documentés séparément. Le journal de septembre sépare ces correctifs du résultat expérimental 86/86 et 8/8.

Oui, pour une mission privée bornée, pas pour toute la production. Le 8 septembre, après une première reproduction refusée pour sortie tronquée, une nouvelle mission passe les mêmes 86 tests et 8 contrôles complémentaires en environ 1 h 26, sans correction humaine du candidat. Le client initiateur est déjà terminé ; Elora poursuit, accepte puis livre une seule réponse, sans doublon lors des deux ticks suivants. Aucun patch n’est appliqué et le modèle permanent reste inchangé.

Les correctifs du harness ajoutent aussi une continuation explicitement bornée et un avis unique par épisode de blocage. Ils sont testés séparément : le nouvel essai réussi n’en a pas eu besoin. Les 94 contrôles ne couvrent pas tous les cas possibles ; une limite CLI reste consignée. Le défaut distinct de présentation des preuves est corrigé par un reçu factuel sans modèle, testé séparément et sans réécrire la réponse historique. Réussite technique et qualité de la restitution restent distinctes.

L’inférence de ce worker peut être entièrement locale, comme GLM via OpenCode dans ces essais. Mais une session Codex ou d’autres agents distants utilisés séparément pour préparer, superviser ou relire le travail consomment leurs propres ressources. Il faut distinguer ces étapes : la génération locale n’implique pas que toute la chaîne utilise exclusivement la station. Le banc ne mesure pas la facturation du compte de l’opérateur.

Parce que ce ne sont pas les mêmes compromis. Ollama maximise la simplicité opérateur. vLLM vise le débit, la concurrence, les lots d'évaluation et les modèles plus lourds quand le matériel suit. llama.cpp vise le contrôle bas niveau, les modèles GGUF, les grands contextes et les hôtes GPU ou CPU dédiés. Dans les trois cas, Elora reste le control plane: ces runtimes ne possèdent ni mémoire, ni routing, ni policy.

elora-runtime status PROFIL --json, elora-runtime doctor --all --json et elora-provider runtimes --json --probe distinguent configuration, disponibilité et liens avec les providers. Un smoke explicitement demandé appelle le modèle ; ni un endpoint joignable ni un smoke réussi ne certifient ses réponses.

Le lifecycle géré de llama.cpp est une option séparée : configuration privée approuvée, actifs déjà locaux et gestionnaire systemd utilisateur. Sans cette configuration, Elora conserve le chemin manuel et ne lance pas de grand modèle. elora-runtime managed status local_llama_cpp --json inspecte cette option. Ses preuves lient configuration, moteur, poids, alias et endpoint ; une dérive bloque, un processus étranger n'est jamais adopté. Un arrêt opérateur désarme sa relance ; un arrêt de service conserve le désir antérieur pour la reprise. Le redémarrage exige des preuves de propriété et de nettoyage, sans adoption d'un processus étranger. Le core et les workers déterministes ne dépendent pas de cette option.

Parce qu’une déclaration, une configuration, un endpoint disponible et une mission réussie sont des preuves différentes. Le registre évolue avec les capacités déclarées ; le nombre d'entrées activées ne garantit jamais autant de workers actuellement utilisables. elora-provider activation-plan --json expose les contrats et les exigences manquantes, sans génération. --probe vérifie les endpoints configurés avec des appels bornés. Le contrôle Codex tient compte de la version de la CLI et du profil réellement lu : un ancien profil ignoré bloque désormais la readiness au lieu de produire un faux positif. Un changement de machine, de configuration ou de runtime peut donc réduire le nombre prêt. Les entrées dormantes ne sont pas activées automatiquement. Seule une mission contrôlée prouve ensuite l’exécution et ses résultats ; ni un compteur vert ni un probe réseau ne prouvent la qualité.

Parce qu'un verbe d'action ne suffit pas à créer une autorité sûre. execution_general et execution_ops sont des réponses locales proposal-only sans worker, queue ni effet externe: Elora décompose vers une capacité nommée, pose une question ciblée ou redirige une demande de procédure vers execution_ops_runbook. Une mutation réelle exige une CLI déterministe, une policy, les approvals adaptés et un contrat d'agent exact. Le seul fallback de mission V1 est le binding explicite de code difficile vers local_code_worker / local_code_agent; les alias Hermes dormants ne sont jamais utilisés comme agents génériques.

Non. C'est un discriminateur historique du registre qui sépare les entrées worker ou overlay de la forme chat-compatible; plusieurs workers déterministes réels et overlays Hermes/Codex configurés le portent encore. Il ne décrit ni la configuration, ni la disponibilité live, ni le droit d'exécuter. Pour décider, il faut lire activation_state, ses checks et le binding exact route + task class + provider + agent. Une entrée peut donc avoir kind: "stub" et être activation_ready, ou rester bloquée pour une raison explicite. Pour examiner une autre déclaration, utiliser elora-provider activation-plan NOM --json. Dormant ne veut pas dire simple clé manquante: son activation doit répondre à un besoin concret, avec route, agent nommé, contrat de compétence et policy cohérents. Les paramètres et secrets éventuels vont dans le fichier privé ~/.config/elora/elora.env, jamais dans le dépôt ou le chat; un probe puis une mission contrôlée valident ensuite disponibilité et exécution séparément.

Pour la chirurgie de dépôt, le contrôle versionné sxcodex doctor --json vérifie CLI, authentification et profil effectif, puis le binding exact codex_specialist / repo_surgery_agent / rewrite_xhigh doit concorder avec la route autorisée. Le chemin généraliste séparé utilise codex_general_worker / codex_general_agent et son propre doctor elora-connected. Le modèle de cette conversation n'est pas implicitement celui du worker. Un refus de sandbox ou d'authentification reste un blocage, pas une raison de passer en accès illimité. Readiness, tentative, exécution réussie et qualité restent distinctes.

Il n'y a pas de raison de limiter leur modèle à la programmation. Elora distingue désormais la chirurgie de dépôt du travail généraliste sur un dossier fourni : analyse, planification, rédaction ou revue. codex_general_agent et grok_general_agent partagent ce contrat, avec un choix explicite du moteur et les mêmes gates Elora. Le client est un moyen d'exécution, pas un métier ni l'identité d'Elora.

Ce profil ne donne pas automatiquement tous les outils du client : ni mémoire personnelle exportée, ni hooks/MCP hérités, ni publication ou modification du core. Elora conserve le résultat et les preuves techniques, pas le raisonnement privé brut. Une session expirée ou un client en échec doit être rétabli avant une nouvelle tentative autorisée ; ce n'est pas une révision de contenu à répéter automatiquement. Une révision reprend les sources autorisées, sans effacer les tentatives précédentes ni leurs limites ; un dossier altéré ou non vérifiable bloque la reprise. Les capacités supplémentaires demandent un contrat adapté ; un bon résultat de modèle ne remplace pas les sources, les tests ou le jugement opérateur.

Non. L'enqueue normal refuse une mission provider-backed avant de créer prompt ou queue si la route, la task class, le provider, le worker, le profil et l'agent de domaine exacts ne forment pas un binding activation_ready. Un profil partagé ne permet donc jamais de substituer un agent d'un autre domaine. /mission TEXT route d'abord vers un agent de domaine exact; sans délégation sûre, Telegram demande /mission AGENT :: TEXT. Il n'existe plus de fallback générique implicite vers Hermes ou Codex, et l'override optionnel ELORA_MISSION_DEFAULT_AGENT doit passer le même gate. Pour couvrir aussi sxqueue, les items historiques et un changement de readiness entre planification et lancement, le core recalcule ce gate après not_before et avant approval ou commande. Pour un agent Hermes exact, router, enqueue et core utilisent le même probe local /models, read-only et sans génération; un endpoint distant, un modèle absent ou un échec réseau ferme le gate. Les autres gates restent sans probe réseau. Un item arrivé à échéance et devenu non prêt passe en failed avec provider_activation_blocked; un item futur reste pending jusqu'à son échéance. Les snapshots restent inspectables sous payload.provider_activation_gate et execution.provider_activation_gate. Un worker déterministe bas niveau sans binding provider garde explicitement l'état not_applicable pour la queue manuelle, mais cela ne le transforme pas en agent de mission.

Pas comme moteur d'inférence : Elora accepte d'autres endpoints locaux compatibles. Les dépendances requises doivent néanmoins rester explicites. L'option llama.cpp gérée utilise actuellement l'inventaire des modèles résidents d'Ollama pour sa sécurité mémoire ; une panne durable de cet inventaire arrête le modèle qu'elle possède. Elle ne prétend donc pas être entièrement indépendante d'Ollama. Sans cette option configurée, ce garde ne devient pas une dépendance du core ou des chemins manuels.

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; elora-models select --task TASK --json assemble la tâche, la capacité, le provider retenu, le runtime préféré, le modèle configuré et le modèle recommandé. C'est un cookbook et un contrat de sélection local, pas un benchmark: il ne télécharge rien, n'appelle pas le modèle, ne modifie pas le routing et ne prouve pas la qualité réelle du modèle.

Non. elora-provider compare est dry-run/proposal-only par défaut. Il peut comparer des avis locaux et natifs (--provider explicites) sur un paquet figé, sans vote ni score. Un appel local exige --execute-local; un externe exige aussi --allow-connected. Un benchmark reste un harness mesuré.

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.

Partiellement. Le control plane, le cockpit, les commandes, la queue, l'inspection et les workers déterministes peuvent rester utilisables. La readiness passe toutefois en warning, pas en ready: la compréhension sémantique libre, les réponses naturelles, le rendu final assisté par modèle et les agents model-only sont dégradés ou indisponibles jusqu'au retour d'un provider compatible. Elora rend cette limite visible au lieu de prétendre qu'un fallback déterministe comprend tout.

Non. Le 10 septembre 2026, Hermes v0.21.1 remplace v0.20.2 sur un tag stable épinglé. Elora adapte le transport des prompts par fichier et conserve explicitement ses limites de tours. Un appel GLM local et son export de session ont été vérifiés ; cela ne qualifie pas tous les outils. Hermes reste un overlay optionnel : mémoire, policy, routing, approvals et acceptation restent dans Elora, sans activation implicite des nouveaux plugins ou du navigateur.

Non. La maintenance du 10 septembre met à jour Hermes, OpenCode vers 1.18.30 et SearXNG, avec essais locaux et retour arrière. OpenCode sépare désormais la réponse de ses traces et une erreur reste un échec même si le client termine sans code d'erreur. Un test SearXNG retrouve des sources ScalarX, sans garantir tous les moteurs ni résoudre automatiquement les CAPTCHA. Au 11 septembre, Codex CLI 0.154.0 et Ollama 0.34.0 sont actifs ; les essais locaux bornés de GLM sur GPU, JSON structuré, génération de code et réponse du modèle principal passent. Ils valident la compatibilité du moteur, pas toutes les missions. Le script dédié ne remplace que les composants restant à mettre à jour et conserve leur état initial pour le retour arrière ; son lancement en root n'accorde aucun privilège permanent aux agents et les commandes Elora restent exécutées sous le compte opérateur. Ni une version récente ni un moteur disponible ne remplacent la vérification du livrable.

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.

Oui : le dialogue généré et le rendu final d'une mission chargent les fichiers de la persona active, pas seulement son nom. Le contrat du rôle reste séparé ; sxchief prompt --json montre le contexte effectif. Avant d'utiliser une reformulation finale, Elora contrôle la conservation des références et des chiffres, puis demande une revue locale du sens, des limites, de l'objectif et du style. Un défaut de présentation corrigeable peut donner lieu à une seule correction, suivie d'un nouveau contrôle, dans le même délai. La persona ne valide pas le livrable et ne possède aucune permission. Un texte trop grand n'est plus coupé silencieusement ; si le rendu ou sa revue échoue, le document accepté reste disponible. Ce contrôle est inspectable mais probabiliste : il ne garantit ni une fidélité parfaite ni une qualité de style universelle.

Pour les nouveaux mandats généralistes, Elora exige un contrôle local lié à l'objectif complet, au dossier fourni et au livrable exact. Le contrat est distinct de celui des équipes Hermes. Un défaut étayé peut déclencher une correction bornée ; une panne du critique entraîne uniquement la reprise du contrôle, sans relancer aveuglément le producteur. Les anciens mandats ne reçoivent pas de permissions supplémentaires. Un avis favorable reste un jugement modèle, pas une preuve de vérité ni un avis inventé de Christophe ; les sources, les contrôles déterministes et les limites restent inspectables.

Les chemins Chromium directs ne désactivent plus implicitement le sandbox ni la vérification des certificats. La régénération des profils Hermes retire l'ancienne exception automatique ; une exception définie dans la configuration source de l'opérateur reste distincte et n'est pas une qualification de sécurité. Un échec ne déclenche pas une relance moins isolée. Cela ne prouve ni la résolution des CAPTCHA, ni la disponibilité du navigateur de recherche automatique, qui garde ses propres exigences.

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.

Non. Éviter les refus injustifiés compte, mais cela ne garantit ni la justesse, ni le respect des consignes, ni une réponse achevée. Ces dimensions sont évaluées séparément. Un LoRA peut adapter certains comportements ; il ne remplace ni la vérification des résultats ni la continuité des missions. Le contrôle des actions et de la mémoire reste à Elora, indépendamment du modèle.

Les essais du 15 septembre trouvent des répétitions chez Supergemma et des surinterprétations chez GLM-4.7-Flash dans les configurations testées. GLM-5.3-Flash local améliore certaines réponses, mais ne réussit pas tous les critères. Des avis favorables du critique ont aussi laissé passer des défauts de fond. Disponibilité, protocole valide, justesse et satisfaction restent donc distincts. GLM-5.3-Flash UD-IQ1_S est désormais utilisé comme primaire local provisoire sur l'hôte principal, avec les embeddings séparés. Cette activation technique respecte le choix local de l'opérateur ; elle ne transforme pas les échecs observés en réussites et ne qualifie pas Flash pour toutes les missions.

La station utilise GLM-5.3-Flash UD-IQ1_S, pas le modèle complet ni nécessairement la précision et les réglages des benchmarks. La tâche, les outils et les budgets comptent aussi ; leur rôle exact doit être mesuré. La révision qualité demande max et retire le quota natif de raisonnement, sans supprimer les contraintes de contexte, de durée et de mémoire. La fiabilité générale n'est pas acquise par ces réglages.

Le fichier modèle vérifié annonce 1 048 576 tokens de contexte natif, mais la fenêtre locale effectivement chargée est de 262 144 tokens dans un seul slot. Un essai isolé retrouve trois codes exacts dans 75 510 tokens d’entrée, sans troncature. Ce n’est pas une qualification générale de compréhension sur 262 144 tokens. La mémoire CPU/GPU du GB10 est partagée, et les limites des clients restent distinctes. Retirer un quota local avec -1 ne retire ni le délai ni les contrôles mémoire ; une expiration sans réponse finale reste un échec, pas un verdict. Les plafonds distants et la confidentialité ne sont pas élargis.

C'est une option, pas une obligation. Elora distingue la compréhension proposée, la validité des données produites et l'autorisation d'agir. Un schéma structuré peut imposer un format correct sans garantir le sens. Si un modèle plus petit perd des contraintes ou oblige à des chargements fragiles, le modèle local plus fort peut aussi assurer cette première lecture. La qualité et la continuité priment sur la vitesse.

Non, à lui seul. Il faut aussi des actifs locaux, un démarrage indépendant des services extérieurs, une marge mémoire suffisante et aucun repli distant indispensable. Les profils Hermes locaux sont normalisés pour retirer les replis hérités, mais leur configuration ne certifie pas le blocage de toute autodécouverte interne. Hermes reste donc optionnel. Sans Internet, les documents locaux restent exploitables ; les faits actuels du web ne deviennent pas vérifiables par magie.