Providers et workers

Elora peut utiliser plusieurs modèles et agents, mais aucun d'eux ne devient Elora. Le control plane choisit, borne, audite et conserve la continuité.

Pourquoi les runtimes locaux comptent

Ollama donne à Elora un socle local simple pour inférence, génération et embeddings. vLLM ajoute un chemin haut débit pour modèles lourds et traitements concurrents. llama.cpp ajoute un chemin bas niveau, contrôlable, compatible GGUF et adapté aux hôtes dédiés. Dans les trois cas, Elora consomme un endpoint OpenAI-compatible ou un contrat CLI: le runtime reste un worker remplaçable.

Ce n'est pas une obligation idéologique: c'est une condition pratique d'indépendance. Si un provider cloud disparaît, change ses prix, limite une API ou devient inadapté, Elora doit continuer à répondre, classer, router, récupérer du contexte et exécuter des workflows locaux.

La qualité prime sur la vitesse : un petit modèle d'accueil n'est pas un passage obligé avant le modèle chargé du travail. Son interprétation doit être évaluée sur des demandes variées et rester une proposition. La disponibilité hors ligne dépend aussi du démarrage, de la mémoire nécessaire aux modèles et aux embeddings, et des replis réellement configurés — pas seulement d'une adresse localhost. Au 23 septembre 2026, sur l'hôte principal, le raisonnement local et le code local utilisent GLM-5.3-Flash UD-IQ1_S, alias glm53-flash-iq1s, servi par llama.cpp géré en loopback sur le port 18088. Une lecture seule de /props confirme un seul slot et un contexte effectif de 262144 ; ce contrôle n'a pas lancé de nouvelle génération. Ollama conserve les embeddings. GLM-4.7-Flash est une alternative historique, et GLM-5.2 n'est pas le défaut local. Supergemma n'est pas un consommateur concurrent par défaut. La qualité du modèle et la capacité configurée ne sont pas l'autorité d'Elora. L'activation du runtime n'est pas une qualification générale : les défauts de réponse et les faux avis favorables restent consignés, et les résultats exigent toujours leurs vérifications.

Réglages locaux et qualité réelle

La révision qualité du 16 septembre demande l'effort natif max et retire le quota de raisonnement de 4 096 tokens. Elle conserve les mêmes poids Flash UD-IQ1_S et un seul slot. Le 17 septembre, la fenêtre effectivement chargée passe de 65 536 à 262 144 tokens, avec un contrôle de la mémoire disponible. Les plafonds de sortie propres aux phases Elora et les délais des workers restent distincts ; aucun plafond natif Hermes non prouvé n'est revendiqué. Davantage de réflexion ne signifie ni génération illimitée ni autorité supplémentaire.

Les clients locaux concernés héritent des réglages explicites du serveur ; le transport Hermes transmet bien max au parent et aux enfants. Ces contrôles prouvent la configuration, pas l'amélioration des réponses. Le nouvel essai de critique sur un dossier volumineux n'a pas fourni de réponse en une heure ; les délais locaux ont ensuite été adaptés au débit mesuré. La fiabilité générale reste à établir : les erreurs et faux avis favorables observés ne sont pas effacés, et aucun réglage n'est annoncé comme optimal.

Le GGUF vérifié annonce une capacité native de 1 048 576 tokens : ce n’est ni la fenêtre allouée ni une preuve de compréhension fiable à cette longueur. Sur GB10, CPU et GPU partagent la mémoire ; augmenter le cache de contexte ne doit pas entamer la réserve de sécurité. Cette fenêtre de 262 144 tokens garde les protections existantes et interdit le décalage automatique du contexte. Un essai isolé retrouve les trois codes attendus dans 75 510 tokens d’entrée, sans troncature : cela valide ce cas de recherche, pas la qualité générale sur toute la fenêtre. Les limites propres aux clients restent inspectables et peuvent encore borner un dossier.

La valeur -1, uniquement lorsqu’elle est prise en charge par le transport local, retire le quota de tokens concerné, pas le délai, la limite de contexte ou la possibilité d’annuler. Une fin normale de génération reste distincte d’une troncature ou d’un appel sans réponse finale. Ces marges locales ne changent ni les plafonds des fournisseurs distants ni les règles de confidentialité.

Point de configuration au 23 septembre 2026 : les 17 manifestes Hermes locaux demandent explicitement un raisonnement max, y compris le général elora_exec. Cet overlay reste optionnel et hors chemin critique. max et les budgets locaux plus larges ne signifient ni contexte, ni mémoire, ni durée illimités, ni justesse garantie. La limite client distincte de local_code est un contexte de 262144 et une sortie de 131072 ; elle reste distincte de la fenêtre serveur.

Recherche : contrats intégrés et limites connues

Le chemin reste local-first. Le repli modèle externe exige une tâche publique rédigée séparément, ses modèles autorisés, ses étapes et ses budgets, approuvés pour la session et la version exacte du plan. Le contrôle CLI typé porte l'autorité ; le cockpit le présente, sans la créer. Le même accord est vérifié en preview et au lancement. Pas de copie de mémoire, d'historique ou d'objectif privé ; pas d'accord rétroactif pour un job déjà parti. Un simple « go » n'accorde pas cet export.

Pour les nouveaux accords de recherche, l'identité du transport modèle connecté est séparée du critique local : une panne de GLM ne suffit plus à bloquer une étape publique autorisée dont le client externe est prêt. Les contraintes de confidentialité, le dossier public, l'identité du fournisseur et les preuves de nettoyage restent vérifiés. Les vrais workers généralistes conservent leur contrat de critique ; les anciens accords ne sont pas réécrits. Un avis négatif ne peut pas être remplacé pour obtenir une meilleure note.

Une projection figée relie les passages envoyés au rédacteur, au critique et au vérificateur : 131072 octets UTF-8 par source, 196608 par projection et 128 unités sensibles par défaut, avec omissions visibles. Le début de collecte fournit la date de référence ; ni la date d'une page ni une offre expirée ne devient « aujourd'hui ». Le compteur local porte sur le corps final et son template, avec réserve de sortie et identité du runtime. Il ne prouve ni la marge RAM ni la compréhension de toute la fenêtre de 262144 tokens. Le transport externe conserve une limite distincte de 1048576 octets UTF-8 (1 Mio), framing inclus ; elle ne modifie ni la fenêtre en tokens ni les autorisations d'export.

Ces raccords ont été intégrés et activés localement le 24 septembre. Le contrôle de release passe ses 14 vérifications et huit scénarios isolés ; il ne certifie pas la qualité d'une mission réelle. Au réexamen du 25 septembre, un inventaire de sources a été marqué livré malgré une revue obligatoire non aboutie. Ce résultat n'est pas accepté comme une stratégie complète : les corrections de transmission du dossier et du contrôle de livraison sont installées et qualifiées. La qualification du 25 septembre passe elle aussi 14 contrôles et huit scénarios isolés. Le 26 septembre, le repli autorisé vers Codex produit un véritable brouillon de stratégie et une révision après critique. Sa dernière vérification locale expire sans verdict exploitable : le document est conservé, mais n'est ni validé ni livré. Le parcours ne permet pas encore de reprendre uniquement cette critique. Aucun succès métier ni avis positif de l'opérateur n'est déduit des seuls tests. Le navigateur public Chromium reste non qualifié sur l'hôte : les restrictions AppArmor empêchent encore le sandbox imbriqué. Aucun --no-sandbox, contournement réseau ou assouplissement global n'est présenté comme solution validée.

Les correctifs du contrôle des citations sont installés le 26 septembre : les citations après fermeture de guillemets ou de mise en forme restent attachées à leur phrase, sans emprunter celles de la phrase suivante ; un numéro de titre seul n'est plus traité comme une quantité factuelle. Une proposition d'action ou un élément de structure peut être qualifié explicitement comme non factuel par le critique. Les faits, garanties et droits contractuels exigent toujours leurs preuves. Ces contrôles sont testés, mais le jugement du modèle reste faillible ; aucun ancien verdict n'est réécrit pour devenir favorable.

Les nouveaux correctifs de transport, de diagnostic et de comptage cumulatif des budgets entre tentatives sont installés, après qualification en isolation (111 cas Python et deux scripts de contrôle). Le cumul porte sur un même accord et une même exécution ; il ne s'étend pas automatiquement aux exécutions successeurs. Cette qualification ne valide pas le résultat d'une mission réelle.

La sélection du repli contrôle désormais chaque client séparément : un client indisponible ou dont l'identité a changé ne bloque plus un autre client autorisé et intact. Le client retenu est revérifié avant chaque appel. Les contrôles communs de confidentialité, d'autorité, de preuves, de budget et de fin des processus restent bloquants. La construction du contexte local ne dépend pas de la disponibilité des clients externes.

Le budget d'un nouveau travail est inventorié avant son démarrage effectif. Si cette initialisation échoue, le repli externe reste désactivé pour ce travail, mais une synthèse locale valide peut continuer. Un ancien historique incomplet n'est jamais déclaré vide : sa reprise externe exige une décision explicite de l'opérateur. Ces corrections sont installées et passent ensemble 113 tests Python et la boucle de recherche en isolation ; elles ne certifient pas encore la mission réelle.

Au 27 septembre, le profil de recherche GLM local désactive explicitement la durée maximale totale de ses appels, y compris la critique et les révisions. La connexion conserve un délai de trois secondes ; contrôles mémoire, annulation, délais web et budgets externes ne sont pas supprimés. Ce mode est réservé aux fournisseurs déclarés locaux sur boucle locale et testé sur transport factice. Il ne valide pas rétroactivement le brouillon conservé, ne reprend pas automatiquement sa seule critique et ne change pas les délais des autres parcours.

Muse Spark : intégré, désactivé par défaut

Au 25 septembre, le transport pour muse-spark-1.3-contributor, effort high, et son raccordement au cycle d'agents sont installés et testés hors ligne. L'agent nommé muse_general_agent possède un mandat, un playbook et des critères de qualité ; son fournisseur reste désactivé et la facturation inactive ; aucune génération réelle n'est qualifiée. Il ne remplace ni le primaire local, ni Codex, ni Grok, et ne crée aucun repli automatique.

L'offre Contributor autorise l'entraînement sur les données soumises : store:false n'est pas une garantie d'exclusion. Le contrat exige une classification explicite public ou synthétique portée par la CLI et vérifiée jusqu'au worker ; un texte ou un modèle ne peut pas accorder cette autorisation. Pas de récupération automatique de mémoire ou d'historique. C'est un chemin de rédaction et d'analyse sur contexte fourni, sans outils, avec revue locale obligatoire. Le mode local seul reste prioritaire. Accès API, facturation et essai réel restent nécessaires ; une configuration à grand contexte ne prouve ni sa capacité effective ni une génération longue réussie. Le profil de secours Muse du client Codex reste un mécanisme distinct.

Runtime readiness

Le runtime local est maintenant inspectable comme capacité séparée: elora-ollama doctor --json vérifie binaire, API, PID, alignement provider et modèle; profiles --json expose les profils local_ollama, local_vllm, local_llama_cpp, local_dgx_gb10_llama_server et remote_ssh_llama_server; launch-plan --all --json transforme ces profils en commandes opérateur; logs --json --lines N donne une lecture bornée des logs. elora-runtime doctor --all --json donne aussi la readiness générique. elora-readiness matrix inclut ce check sous local_runtime, et le cockpit peut lire /api/local-runtime.

Les profils vLLM, llama.cpp, DGX/GB10 et SSH llama-server ne sont pas des launchers automatiques. Elora peut consommer un endpoint OpenAI-compatible local ou tunnelé, mais le démarrage d'un serveur lourd ou distant doit rester explicite, borné par policy et auditable.

Un runtime prêt ne vaut pas acceptation qualité. Le smoke local prouve que le modèle configuré répond, mais le contenu généré reste vérifiable. GLM-4.7-Flash reste une alternative historique ; supergemma4-31b-abliterated:q4_k_m reste un modèle local documenté. Leur rôle dépend de la configuration effective de l'hôte, pas de l'identité d'Elora. Le primaire courant est GLM-5.3-Flash. Un modèle plus lourd comme GLM-5.2 exige un runtime adapté et explicitement configuré et n'est pas le défaut local. Les gates de claims, result acceptance et patch acceptance restent l'autorité.

TimesFM et forecasting local

TimesFM ajoute une capacité analytique locale pour prévoir des séries temporelles: ventes, charges, métriques ops, signaux business, historiques de tickets ou tout flux numérique exploitable. Elora ne l'utilise pas pour parler ou raisonner en général. Elle l'appelle comme un worker spécialisé qui reçoit une série, produit des artefacts et marque le résultat comme hypothèse.

Le chemin nominal est timesfm_local quand l'environnement et le modèle sont prêts. Le fallback baseline_naive permet de tester la route, les artefacts et l'audit sans dépendre du modèle. Les demandes naturelles qui combinent clairement une intention de prévision et un contexte de série temporelle passent par une route Elora command-backed, pas par une mission vague.

Cette séparation évite de confondre prévision statistique, vérité mémoire et décision opérateur.

Workers locaux de contenu

elora-site donne au site_qualification_agent une base déterministe: URL ou fichier HTML, titre, méta-description, headings, liens, texte extrait, evidence table, assessment et recommandations. Cela évite que la prospection commence par une synthèse model-only sans preuve.

elora-docs donne au docs_analysis_agent un chemin local pour Markdown, texte et PDF quand l'extraction est disponible. Il produit un résumé documentaire, des claims candidats et des notes de risque. Le même worker donne maintenant au docs_writer_agent un chemin documentation_update: plan de mise à jour, fichiers cibles, validation notes et journal draft, sans modifier le repo. Ces claims et propositions documentaires deviennent un matériau de revue, pas une mutation automatique.

elora-forecast donne au timeseries_forecast_agent un wrapper queue-compatible autour de elora-timeseries. Il copie les entrées externes dans l'arbre d'artefacts du worker, lance la prévision et conserve forecast, validation et implications sans décision automatique.

elora-prospect donne au prospecting_researcher un chemin local avec scénario E2E isolé pour les dossiers StackX: extraction de preuves visibles, inventaire cible, scoring de compatibilité, contact candidates, brouillon outreach avec disclosure IA et revue. Il ne contacte personne, ne modifie pas de CRM et n'écrit pas en mémoire canonique.

Les ressources StackX fournies à Elora, comme une copie locale du projet ou un script de qualification, servent de références et d'entrées pour futurs workers. Elles ne sont pas le dépôt de développement StackX et ne deviennent pas automatiquement des cibles modifiables.

Sélection d'un moteur

1. Elora classe la demande par type de tâche.
2. Elle applique confidentialité, coût, latence, profondeur attendue et readiness.
3. Elle privilégie le local quand c'est suffisant ou requis.
4. Elle escalade vers un spécialiste connecté seulement si la route l'autorise.
5. Elle journalise le choix réel: provider déclaré, candidat sélectionné, fallback éventuel et résultat.

elora-provider select --capability ... --task-class ... --json rend cette décision inspectable sans appeler de modèle. Pour le code local, elora-code backends select --json ajoute le choix du backend d'exécution: artefact natif déterministe, modèle local de code, ou client OpenCode.

Le doctor provider expose aussi une synthèse plate pour cockpit et tests: nom, état, readiness, localité, worker/profile, modèle et politique d'endpoint. Cette vue évite les diagnostics inutilisables avec des entrées anonymes ou trop imbriquées.

Un compteur provider n'est pas une liste de clés API

elora-provider activation-plan --json explique chaque déclaration non prête sans la rendre artificiellement verte. Il distingue désormais configuration_ready, eligible_for_attempt, live_proven, activation_ready et le scope d'éligibilité. eligible_for_attempt réunit les entrées déjà activation_ready et les seuls endpoints chat configurés bornés à direct_reply_only; ce champ ne contourne jamais le gate exact d'une mission. Le contrat est read-only: aucune inférence, aucun lancement de worker, aucune matérialisation de profil et aucune mutation de provider, routing, policy ou mémoire.

elora-readiness matrix --json et le cockpit consomment ce plan sans probe réseau. Ils affichent les catégories à froid séparément et marquent la preuve live comme non sondée, au lieu de transformer le compteur de compatibilité ready du doctor en un nombre d'agents exécutables. Un inventaire vide, incohérent, dupliqué ou un source contract qui termine en erreur reste explicitement non vert; la vérité par vacuité ne vaut jamais readiness. Le probe de /models reste une action opérateur explicite avec elora-provider activation-plan --probe --json.

kind: "stub" est un discriminateur historique du registre pour les entrées worker et overlay, pas un verdict « non implémenté » ou « non configuré ». Des workers déterministes réels et des overlays Hermes/Codex configurés le portent encore. L'autorité opératoire vient de activation_state, des checks et du binding exact route + task class + provider + agent; kind seul n'autorise ni ne bloque une exécution.

Le registre expose les déclarations activées et dormantes ; leur nombre évolue avec les capacités ajoutées. Une déclaration activée n'est pas une preuve d'exécution : le plan à froid sépare configuration, capacité déterministe, éligibilité à une tentative et absence de preuve live. Codex peut rester bloqué malgré une CLI authentifiée si son profil effectif manque ou est ignoré par la version installée. Les déclarations dormantes restent inspectables par nom mais absentes du routage. activation-plan --probe --json vérifie les endpoints configurés et les modèles annoncés ; il ne garantit pas un total fixe de providers prêts et ne remplace jamais une mission contrôlée.

Une réponse directe peut tenter dans l'ordre un endpoint chat configuré mais non sondé, puis le provider suivant, puis le fallback déterministe. Une mission Hermes reste stricte: le router sonde uniquement le candidat exact par le contrat non mutant sxhermes readiness, sur son /models loopback et sans génération. Une mission Codex de chirurgie de dépôt exige le doctor versionné, le profil effectif rewrite_xhigh dans CODEX_HOME et l'agent exact repo_surgery_agent; cette preuve autorise seulement une tentative et ne prétend jamais qu'une exécution a réussi. L'enqueue puis le core recalculent le gate route + task class + provider + worker + profil + agent avant toute queue effective, approval ou commande. Le code difficile garde son repli exact local_code_worker / local_code_agent. Le worker de recherche locale peut, sous un mandat public explicite, confier une étape à Grok ou Codex après un échec de transport dont le nettoyage est vérifié. Après stagnation locale, une seule révision par un producteur connecté peut aussi repasser devant le même critique ; ni les preuves ni les critères ne sont assouplis. Ce mandat n'autorise aucun export implicite de mémoire. Les classifications génériques execution_general et execution_ops répondent localement sans worker ni effet externe: Elora décompose vers une capacité nommée, clarifie, ou redirige une demande procédurale vers execution_ops_runbook. Une queue manuelle ne contourne pas la readiness; les snapshots restent inspectables dans le payload puis l'exécution.

Types de workers

Codex et Grok au-delà du code

Analyser un dossier, comparer des options, préparer un plan ou rédiger une note ne nécessite pas de produire du code. Les bindings codex_general_agent et grok_general_agent utilisent un contrat commun de travail sur contexte fourni et le cycle existant d'Elora. Ils sont sélectionnés explicitement ; aucune demande locale ou confidentielle n'est exportée par repli implicite.

Sur ce chemin, le modèle produit le texte et Elora écrit les artefacts. Le client reçoit un espace isolé, sans les outils et autorisations personnels ni retrieval mémoire automatique. Cela n'ouvre ni recherche web, ni modification de dépôt, ni publication. elora-connected doctor --engine codex|grok --json distingue préparation, isolation et authentification locale ; seuls les essais réels prouvent l'exécution. Le reçu technique ne certifie pas l'exactitude de l'analyse. Un échec de client exige une inspection et le rétablissement du prérequis, pas une répétition automatique déguisée en révision du texte. Les rôles métier, leurs missions et leurs critères restent définis dans Elora, indépendamment du moteur choisi.

Au 23 septembre 2026, ces profils généralistes sur contexte fourni restent model-only : ils n'exécutent pas le dépôt et n'ont ni web implicite, ni retrieval, ni mémoire privée. Les chemins à outils sont distincts : propositions Codex, GLM local via OpenCode, et sxgrok improve. Le doctor workspace Grok effectif est ready_for_attempt, modèle grok-4.7, effort xhigh. Fast et un effort inférieur ne sont pas le réglage retenu. Cette readiness n'est pas un succès à chaque mission.

Les corrections conservent le dossier autorisé et son intégrité vérifiée. La réponse précédente peut être reprise comme proposition à corriger, jamais comme source ou permission. Aucun contexte mémoire supplémentaire n'est exporté ; un original altéré ou non vérifiable bloque la reprise.

Essais non-code du 16 septembre 2026 : Codex/Astra produit une note de décision sur un dossier fictif comportant des tarifs contradictoires. Après reconnexion, Grok produit aussi une note ; une revue refuse son premier texte trop long. Une nouvelle mission reçoit explicitement le dossier et le brouillon, puis produit une correction conforme. Calculs, citations et limites sont vérifiés indépendamment ; Elora conserve puis livre les résultats par son cycle habituel, sans inventer d'approbation humaine. Ces cas valident ces parcours bornés, pas toutes les missions futures ni une détection autonome de chaque défaut.

Qualification réelle du 7 septembre 2026 : après correction du lancement Codex, de son environnement sandboxé et du choix de contrat qualité, une mission Astra/ultra prépare une proposition isolée sur les métadonnées d’Elora. Syntaxe Bash et six cas indépendants passent ; le cœur accepte la proposition et le superviseur la livre dans la session après le retour du client initiateur. Le dépôt source reste intact et le patch n’est pas appliqué. Les essais précédents refusés sont conservés. Cette preuve qualifie ce parcours borné, pas tous les refactors ni un déploiement autonome. La récupération du superviseur après une panne est observée séparément ; une panne pendant une génération productive et un reboot physique restent à qualifier.

Puissance du modèle et accès aux outils

Un profil de génération de texte n'est pas un exécuteur. Codex dispose déjà d'un chemin de proposition avec outils ; GLM via OpenCode peut lire et éditer les fichiers autorisés, avec validation indépendante par Elora. Les experts Hermes conservent leurs outils selon leur mandat. Donner le meilleur résultat ne signifie pas ouvrir indistinctement les identifiants, la mémoire et la production à tous les modèles.

Le 22 septembre, le profil général Hermes rejoint les profils spécialisés avec un effort max explicite : il héritait encore de medium. Cette correction porte sur la configuration et son passage au client, sans élargir les permissions ni présenter le réglage comme une garantie de qualité.

La CLI sxgrok improve ajoute un chemin distinct pour les propositions Grok avec lecture de fichiers, modifications et commandes dans une copie isolée. Le client connecté conserve son authentification ; les commandes s'exécutent dans un autre espace, sans celle-ci ni réseau. Elora vérifie ensuite le diff, les références protégées et les tests, sans fusion automatique. sxgrok workspace-doctor --json expose la préparation de ce chemin. Le 22 septembre 2026, cette CLI a été qualifiée sur une proposition synthétique : lectures, modifications et commandes réelles dans une copie isolée, contrôles indépendants, original inchangé, sans application automatique. Les outils tournent hors ligne, sans les identifiants du client natif. L’intégration agent nommé, provider, route et formulaire cockpit transporte le contrat explicite de dépôt et de fichiers dans le cycle existant. Le 23 septembre 2026, un cas non-code fictif avec Grok 4.7/xhigh a qualifié le parcours mission, queue, validation indépendante, acceptation et livraison unique en session. L’original reste intact, sans application de la proposition ni feedback inventé. L’avancement a été déclenché par des ticks CLI sur le mandat persistant : ce n’est pas une nouvelle preuve du service de veille résident ni une garantie pour toutes les missions. Il n'y a pas d'export automatique de l'historique de session. Le texte libre n'ouvre pas l'écriture de fichiers. Fusion, déploiement, publication et promotion mémoire restent des décisions séparées.

Hermes comme opportunité, pas comme centre

Les contrats Hermes audités depuis v0.18 renforcent les résultats d'outils, la provenance des sorties, l'isolation des profils et la concurrence des sessions, tout en conservant le proxy local OpenAI-compatible, les handoffs, les diagnostics LSP, les contrôles de mutations, prompt-size, Kanban et le dashboard. Elora peut en tirer parti pour améliorer des workers ou providers, mais ces fonctions restent derrière sxhermes, les agents nommés, la readiness et les gates Elora.

Kanban peut devenir intéressant pour lancer des sous-travaux en parallèle, mais seulement via un adapter Elora qui écrit queue, execution records, artefacts et result acceptance. L'état courant du curator Hermes n'est pas vérifié sur le profil effectif et reste donc inconnu; Elora n'autorise aucune promotion venant de ce curator. Un futur bridge pourrait au mieux produire des propositions inspectables.

sxhermes readiness [--probe] --json inspecte le profil exact sans créer de home ni modifier sa configuration. Le probe optionnel désactive les proxies ambiants, borne le timeout, ne lit que /models, ne génère rien et ne révèle aucun secret. sxhermes doctor --json inspecte la configuration sans lancer automatiquement les diagnostics natifs ; ceux-ci nécessitent une invocation explicite distincte. Le runtime vérifié le 20 août 2026 est Hermes 0.20.2, provider local custom sur Ollama; l'autorité ne bouge pas: mémoire, policy, routing, approvals, acceptance gate et qualité déterministe restent dans Elora.

local_code sans Codex

La route locale de code existe pour éviter que Codex, Claude, Hermes ou un provider connecté deviennent des prérequis. Le worker local_code produit des artefacts inspectables: plan, réponse générée, réponse brute provider quand un modèle local répond, premier bloc de code extrait quand il existe, manifest, validation log, résultat JSON et quality JSON.

Quand ELORA_LOCAL_CODE_BASE_URL et ELORA_LOCAL_CODE_MODEL pointent vers un runtime OpenAI-compatible local, local_code_model propose le code. Le worker déterministe conserve l'autorité sur les fichiers générés, la validation syntaxique possible et les claims. Il ne prétend modifier le repo que lorsqu'un chemin d'exécution local explicite le prouve.

Un modèle de raisonnement/code peut devenir le backend local_code_model par configuration, sur Ollama, vLLM, llama.cpp ou un llama-server tunnelé depuis une machine GPU privée. Sur l'hôte principal, ce rôle est tenu par GLM-5.3-Flash. GLM-4.7-Flash reste une alternative historique. Un modèle frontier comme GLM-5.2 exige un runtime matériel réellement adapté et n'est pas le défaut local. Le nom configuré dans ELORA_LOCAL_CODE_MODEL doit correspondre exactement au tag servi.

OpenCode devient le premier backend client spécialisé derrière local_code. elora-code run --backend opencode --mode analyze l'utilise pour comprendre et documenter un repo en read-only. --mode edit l'utilise comme équivalent local de client de code: création/modification de fichiers dans le repo, commandes locales de validation, status Git avant/après, diff patch, fichiers changés, stdout, stderr, résultat et quality JSON conservés. Si un endpoint local OpenAI-compatible et ELORA_LOCAL_CODE_MODEL sont configurés, Elora expose automatiquement ce runtime local à OpenCode sous elora_local_code/<model>. OpenCode n'obtient ni mémoire, ni policy, ni routing, ni autorité d'Elora.

Qualification réelle du 6 septembre 2026 : GLM-4.7-Flash, piloté par Elora via un OpenCode temporaire, a écrit puis corrigé un script Bash dans un dépôt jetable. Les tests indépendants sont passés de 9/10 à 10/10 après une révision. Ce résultat prouve ce petit parcours, pas une qualité générale ni une installation permanente. Le défaut d’observation révélé par cet essai a ensuite été corrigé : les fichiers changés sont comparés par contenu, type et permissions, même si leur statut Git reste identique. Cette observation couvre les fichiers suivis et non ignorés, pas un confinement complet du dépôt.

Après cet essai, OpenCode 1.18.29 a été installé durablement dans un répertoire utilisateur versionné, avec intégrité vérifiée et profil GLM dédié. L’installation seule n’ajoute pas le client au PATH global et ne l’active pas. Le 7 septembre, son chemin est ensuite déclaré explicitement dans la configuration privée du cœur permanent, qui connaît déjà GLM local. La génération ordinaire garde son backend ; la règle existante d’analyse automatique peut désormais choisir OpenCode disponible. Les propositions exigent toujours leurs contrats explicites : disponibilité du binaire et autorisation d’action restent distinctes.

Le mode distinct proposal raccorde un contrat explicite de fichiers, de tests de référence et de budget à une proposition locale isolée, avec validation obligatoire et correction bornée. Le dépôt source n’est pas modifié. Le modèle édite uniquement les fichiers permis ; Elora construit le patch et les rapports, puis lance elle-même les tests indépendants. Le mandat complet est transmis au worker, distinct du titre court affiché. Le cycle utilise les missions, bindings et gates d’Elora ; le message de succès d’OpenCode ne vaut pas acceptation.

Le 7 septembre 2026, après correction AppArmor ciblée, accord réseau explicite et contrôles natifs, ce parcours est qualifié avec le client installé et GLM local. Un premier essai est refusé pour tentative d’outils interdits ; après correction du cadrage et du handoff, le second produit un script Bash qui passe syntaxe, ShellCheck et dix cas indépendants. La mission livre une seule proposition vérifiée ; un nouveau tick terminal ne lance rien et ne duplique pas la réponse. Sources et tests restent intacts, et le consommateur isolé est arrêté proprement. Cette preuve porte sur ce petit parcours, pas sur la qualité générale du modèle ni une auto-amélioration complète en production.

Une reproduction distincte du 7 septembre sous le cœur et le superviseur permanents lance et suit les workers après retour des clients, mais ne qualifie pas la livraison GLM : 4/10, puis 9/10 et 9/10 cas après deux corrections explicitement demandées, dont la dernière avec un diagnostic précis. Le dernier script traite encore mal un argument supplémentaire à --help. Elora refuse le résultat et arrête pour stagnation, sans appliquer de patch. L’indépendance du client et la qualité du code restent deux critères distincts ; la réussite historique isolée n’est pas effacée.

Un essai séparé du 7 septembre qualifie ce petit parcours avec GLM-5.3-Flash, anciennement Ox Alpha, sur un seul Spark : poids UD-IQ1_S de 93,1 Go, moteur CUDA épinglé, contexte court et serveur loopback temporaire. Les quatre contrôles de protocole passent ; OpenCode produit ensuite un script accepté par Bash, ShellCheck et dix cas indépendants en environ 97 secondes. C’est un seul essai worker, avec correction interne pendant l’appel, sans intervention extérieure. Cette preuve ne vaut ni supériorité générale, ni validation du superviseur permanent, ni activation en production : modèle actif, sources et tests initiaux restent inchangés, aucun patch n’est appliqué et le serveur expérimental est arrêté.

Un second exercice, plus large, demande trois modules Python et une interface JSON pour un planificateur hors ligne. Après plusieurs limites de génération, un quota de réflexion et les limites de contexte/sortie annoncées à OpenCode permettent une compaction suivie d’une reprise réelle. La première proposition complète passe 85 des 86 contrôles figés ; une revue ajoute huit contrôles CLI séparés, dont quatre échouent. Une correction entièrement écrite par GLM atteint ensuite 86/86 et 8/8, plus la compilation, sans affaiblir les tests. Cette correction prend environ 1 h 31 et traverse trois compactions ; les six exécutions natives cumulent environ 4 h 14, hors chargements et pauses. Le serveur expérimental est arrêté et la stack permanente reste prête. C’est une qualification multi-fichiers bornée, pas une réussite rapide ni une validation générale de l’autonomie : aucun patch n’est appliqué à Elora, aucun modèle permanent n’est activé, et les ajustements du banc ne corrigent pas le runtime de production. Ce planificateur n’est pas son scheduler réel.

La première reproduction du 8 septembre par mission persistante n’atteint pas ce résultat : après environ 66 minutes et une compaction réelle, le client termine sur une limite de sortie sans modifier les stubs. Aucun contrôle du candidat ne peut alors être exécuté. Elora refuse l’acceptation et n’utilise pas une révision qualité pour recommencer à l’identique. Cette tentative révèle aussi l’absence d’avis automatique de blocage dans la conversation ; ses ressources privées sont arrêtées et ses preuves conservées.

Après les correctifs, une nouvelle mission persistante privée réussit les mêmes 86/86 et 8/8 contrôles, plus la compilation, en environ 1 h 26. GLM écrit les quatre fichiers sans correction humaine, dans un seul worker, sans révision qualité ni continuation explicite. Le superviseur poursuit après le retour du client ; Elora accepte et livre une seule fois dans la session d’origine, sans doublon lors des deux ticks suivants. Les ressources expérimentales sont ensuite arrêtées et les six composants permanents restent prêts. Cette preuve ne vaut ni activation en production, ni perfection du code : une revue statique relève notamment un cas JSON très profondément imbriqué absent des 94 contrôles. Le texte livré expose aussi un défaut distinct de présentation des preuves, conservé dans l’audit.

Qualité du harness : correctifs de septembre

Après ces expériences, le dépôt de développement contient des corrections distinctes : les limites de contexte et de sortie sont déclarées, inspectables et liées à l'autorisation de proposition au GO ; la supervision vérifie l'arrêt des descendants avant de figer les fichiers et leurs empreintes. Un refus d'autorité est distingué d'un défaut de qualité révisable, afin de ne pas relancer inutilement le worker. Les tests déterministes de ces contrats passent ; les résultats historiques restent rattachés à leur run, sans certification implicite des sources actuelles.

Le client OpenCode 1.18.29 installé a aussi été vérifié nativement dans un contrôle isolé, réseau fermé et configuration projet contradictoire en lecture seule : il retient les limites Elora de 32 768 tokens de contexte et 8 192 de sortie, avec compaction automatique activée. Ce contrôle de configuration n'appelle aucun modèle et ne prouve pas une compaction réelle. À la date de ce contrôle, le profil alors permanent GLM-4.7 n'avait pas été modifié : ses limites inconnues bloquaient le mode proposal jusqu'à leur déclaration explicite correspondant au serveur. Ces limites OpenCode de 32 768 / 8 192 et ce profil GLM-4.7 sont une preuve historique du début septembre, pas les défauts du 23 septembre. Ces corrections du checkout n'étaient ni une qualification GLM en production, ni l'activation courante de Flash, ni une publication. Les régressions ciblées de mission, correction et livraison passent avec des workers inertes.

Les corrections du 8 septembre distinguent aussi génération tronquée, absence de modification et échec des tests. Un contrat peut autoriser une seule continuation dans la même session privée OpenCode et le même budget de temps total ; ce n’est pas une révision qualité supplémentaire. Les nouveaux mandats correctement rattachés à une conversation disposent d’un avis unique par épisode de blocage, sans relance du modèle ni faux message de réussite. Ces mécanismes sont testés avec des workers inertes ; la mission GLM réussie n’a pas eu besoin de les déclencher.

La restitution des propositions est également corrigée : Elora présente directement les fichiers et commandes de validation attestés par le résultat natif du run accepté, sans les faire réinterpréter par un modèle. Un reçu indisponible reste explicite et ne devient pas une réussite inventée. Ce correctif est vérifié séparément ; la réponse imparfaite de l’essai reste dans son historique, et une proposition vérifiée ne devient pas un patch appliqué.

Ce mode réutilise actuellement la CLI Codex uniquement comme adaptateur local de sandbox, sans compte ni inférence OpenAI dans le worker local. Une supervision ou une revue séparée par un agent Codex reste une consommation distincte. L’accès au modèle local exige une autorisation réseau séparée : la frontière native disponible porte sur l’hôte loopback et tous ses ports, pas sur le seul port de GLM. Sans acceptation explicite de cette frontière, le plan reste bloqué. La validation conserve le réseau fermé ; application du patch, publication, mémoire canonique et déploiement demeurent des décisions séparées.