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.

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é est câblé, mais le contenu généré reste vérifiable. GLM-4.7-Flash est installé comme spécialiste pratique de raisonnement et de code sur le GPU 32 Go; supergemma4-31b-abliterated:q4_k_m reste le modèle quotidien et le fallback connu. GLM-5.2 est un candidat frontier 753B, pas un défaut workstation. 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 full E2E-proven 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.

Types de workers

Hermes v0.18 comme opportunité, pas comme centre

Hermes v0.18 renforce les contrats de 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. Le curator Hermes est en pause sur le profil Elora et ne promeut rien dans Elora: un futur bridge pourrait au mieux produire des propositions inspectables.

Le diagnostic sxhermes doctor --json expose la version, le commit, le statut de mise à jour Hermes et les providers auxiliaires. Le runtime vérifié est Hermes 0.18.2, profil elora_exec, provider local custom sur Ollama. C'est utile pour le cockpit et l'audit, mais 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.