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 Ollama compte

Ollama donne à Elora un socle local d'inférence, de génération et d'embeddings. Concrètement, Elora peut pointer un provider OpenAI-compatible local vers l'instance Ollama, choisir un modèle principal, un modèle de raisonnement ou un modèle de code, puis vérifier l'état par des commandes locales.

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_llama_cpp et remote_ssh_llama_server; logs --json --lines N donne une lecture bornée des logs. elora-readiness matrix inclut ce check sous local_runtime, et le cockpit peut lire /api/local-runtime.

Les profils llama.cpp 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 GPU distant doit rester explicite, borné par policy et auditable.

Un runtime prêt ne vaut pas acceptation qualité. Le smoke OpenCode local prouve que le modèle supergemma4-31b-abliterated:q4_k_m est câblé dans le backend local, mais le contenu généré reste vérifiable. 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.16 comme opportunité, pas comme centre

Hermes v0.16 apporte un proxy local OpenAI-compatible, du handoff de session, des boutons clarify, des diagnostics LSP, une vérification de mutations de fichiers, des security advisories, des signaux prompt-injection, prompt-size, desktop/gui, un skill curator, Kanban et de nouvelles surfaces/toolsets. 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 ne promeut rien dans Elora: il peut au mieux produire des propositions inspectables.

Le diagnostic sxhermes doctor --json expose maintenant la version, le commit, le statut de mise à jour Hermes et les providers auxiliaires. Les profils Elora sont migrés au schéma Hermes v29 avec compression auxiliaire locale. 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 local plus lourd de raisonnement/code, par exemple Qwen sur Ollama ou un llama-server tunnelé depuis une machine GPU privée, peut devenir le backend local_code_model par simple configuration. Elora ne le lance pas implicitement: le runtime doit être démarré ou rendu accessible par l'opérateur, puis sélectionné et audité comme provider remplaçable.

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.