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. Sur l'hôte principal, GLM-5.3-Flash UD-IQ1_S est le primaire local provisoire, partagé par les routes de raisonnement et de code dans un seul slot ; Ollama conserve les embeddings. Supergemma et GLM-4.7 ne sont pas des consommateurs concurrents par défaut. 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é.

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 et supergemma4-31b-abliterated:q4_k_m font partie des modèles locaux documentés; leur rôle dépend de la configuration effective de l'hôte, pas de l'identité d'Elora. Un modèle plus lourd comme GLM-5.2 exige un runtime adapté et explicitement configuré. 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 seul fallback de mission restant est le binding exact local_code_worker / local_code_agent pour le code difficile. 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.

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.

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, par exemple GLM-4.7-Flash ou Qwen sur Ollama, vLLM, llama.cpp ou un llama-server tunnelé depuis une machine GPU privée, peut devenir le backend local_code_model par configuration. Un modèle frontier comme GLM-5.2 exige un runtime matériel réellement adapté. 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. Le profil permanent GLM-4.7 reste inchangé ; ses limites inconnues bloquent le mode proposal jusqu'à leur déclaration explicite correspondant au serveur. Ces corrections du checkout ne sont ni une nouvelle qualification GLM en production, ni une activation 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.