domain_agents
Elora reste l’interlocutrice et le centre de décision. Son organisation distingue désormais dix-neuf rôles, chacun avec un mandat, une persona et des exigences de qualité. Un rôle n’est ni un modèle, ni un nouveau worker : ses capacités opérationnelles restent reliées aux agents techniques et aux autorisations du core.
Pour les missions elora-execute liées à codex_general_agent ou grok_general_agent : charge complète et objectif opérateur accepté lié par digest séparé ; local, hors-ligne et exclusion fournisseur sur cet objectif seul, jamais le texte source. Documents joints non fiables malgré faux titres ou échappements. Sans objectif séparément vérifiable, refuser avant file et modèle. --mission/--prompt-file non lié : fichier entier = instruction ; pages dans --context-file. Interdits opérateur inchangés. Pas d'immunité universelle.
Les mandats récurrents sont désormais explicites : agent nommé, dossier figé, cadence, échéance et plafond de tentatives. Ils réutilisent les missions, la file et la supervision d'Elora, sans créer un second ordonnanceur de workers. Deux cycles suivis d'un arrêt au plafond ont été qualifiés avec un transport modèle simulé ; aucun métier réel n'est activé par défaut. Cette preuve de fonctionnement ne mesure pas la qualité métier.
Le métier de l'agent et son moteur sont distincts. Codex et Grok peuvent aussi analyser, planifier, rédiger ou revoir un dossier : les bindings généralistes codex_general_agent et grok_general_agent réutilisent le cycle d'Elora sur un contexte fourni explicitement. Ils n'exportent pas automatiquement la mémoire et n'héritent pas des outils personnels du client. Les rôles organisationnels s’appuient sur des capacités techniques exactes ; leur présence au catalogue ne prouve pas qu’un worker soit prêt ni qu’un résultat soit bon.
Les nouveaux mandats généralistes ajoutent une critique locale liée au dossier et au livrable exact. Elle peut demander une correction dans le mandat existant ou exposer un prérequis manquant. Une panne de cette revue ne relance pas le producteur ; un avis favorable ne prouve pas la justesse du contenu. La mise en voix persona est contrôlée séparément : une correction de présentation peut être tentée dans le même délai, puis revérifiée. Le document accepté est conservé si la fidélité du rendu n'est pas établie.
elora-provider compare peut, avec des --provider explicites, juxtaposer les avis de local_primary, codex_general_worker et grok_general_worker sur le même paquet UTF-8 figé (fichiers réguliers, sans export mémoire/dépôt, sans outils). Par défaut c'est preview/proposal-only ; --execute-local lance le local, les externes exigent aussi --allow-connected. Pas de fan-out natif implicite, pas de vote ni de score automatique.
Pour les corrections du core, repo_surgery_agent peut utiliser le contrat isolé sxcodex improve : périmètre explicite, copie des seuls fichiers autorisés, diff et validations indépendantes. Le modèle reste remplaçable. Profil effectif, authentification et bac à sable doivent être opérationnels ; une proposition testée n’autorise pas son application ou son déploiement sur l’Elora active.
Au 23 septembre 2026, les noms de modèles décrivent la configuration, pas l'identité d'Elora. Le raisonnement et le code locaux de l'hôte principal utilisent GLM-5.3-Flash UD-IQ1_S. Le profil Elora rewrite_xhigh sélectionne Astra (gpt-6-astra) à l'effort ultra ; ce choix reste celui de ce profil. Le doctor workspace Grok est ready_for_attempt pour grok-4.7 à l'effort xhigh : une préparation, pas une réussite de chaque mission. Les profils généralistes à contexte fourni restent model-only, sans exécution de dépôt ni mémoire privée. Les chemins à outils sont distincts : propositions Codex, GLM local via OpenCode, et sxgrok improve. 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. Pas d'export automatique d'historique, pas de fusion ni de publication.
Au 25 septembre, Muse Spark Contributor est intégré comme spécialiste optionnel sur dossier explicitement déclaré public ou synthétique. Son agent nommé et son cycle sont testés hors ligne ; le fournisseur reste désactivé et la facturation inactive ; aucun résultat réel n'est qualifié. Ce chemin exige une revue locale, ne donne aucun accès automatique à la mémoire privée ni aux outils et ne remplace pas les workers existants.
Elora ne veut pas seulement lancer des agents. Elle doit lancer les bons agents, avec la bonne mission, les bonnes bornes, les bons artefacts et le bon niveau d'exigence.
Le catalogue est inspectable avec elora-agent organisation list --json. Il sépare définition, liaison à une capacité, validation, activation et suspension. Une observation absente reste not_checked, pas un succès ou un échec inventé.
Ao suit la cohérence et prépare les arbitrages. Mystra porte l’architecture, Elminster la profondeur stratégique, Cyric la contradiction et la revue, Savras la veille. Ao ne remplace ni Elora ni son orchestration interne et ne crée pas un second ordonnanceur.
Gond construit, Torm prépare et encadre les opérations, Helm examine la sécurité, Drizzt garde la continuité du support. Une procédure préparée n’est pas une action exécutée sur un serveur.
Khelben structure les priorités professionnelles ; Mirt développe les approches commerciales. Waukeen et Tyr portent les mandats finance et juridique, mais n’ont pas encore d’intégration dédiée. Aucun paiement, engagement ou envoi n’est autorisé par un nom de rôle.
Oghma organise la connaissance, Trouveur travaille l’écriture, Eilistraée la direction créative. Lathandre accompagne le contexte de santé, Yondalla la logistique personnelle, Sunie la dimension relationnelle. Les deux derniers n’ont pas d’intégration dédiée ; un worker texte ne devient pas un moteur audio ou vidéo.
Les alias Arunsun et Bâton noir désignent le même Khelben. Chaque rôle conserve ses limites et sa qualité attendue : ce sont des exigences à vérifier, pas des notes déjà obtenues. Les personas sont des fichiers effectivement compilés, sans droits supplémentaires ni faits opérationnels préécrits.
Une mission peut fixer son rôle avec elora-execute mission --role ROLE --playbook PLAYBOOK. Son persona est conservé dans l’exécution et transmis au worker par le chemin habituel. Sur le chemin conversationnel, l’interprétation locale peut proposer un rôle explicitement demandé : Elora vérifie sa compatibilité, l’affiche dans le plan et conserve ce choix au « go ». Les tests du raccord utilisent un classifieur simulé ; ils ne certifient pas la compréhension de chaque formulation par tous les modèles.
Les contributions encadrées passent par les commandes d’Elora : responsable persistant, objectif, périmètre, limites, résultat vérifiable et revue avant retour. Le parcours Drizzt → Torm a été testé jusqu’au retour des artefacts, sans fermer le dossier de Drizzt. La procédure Apache utilise une approbation explicite et un simulateur local désactivé par défaut ; elle ne redémarre aucun serveur réel. Ce socle n’est ni une conversation libre entre agents, ni l’ingestion automatique de leurs propositions.
La livraison d’une équipe distingue maintenant l’acceptation technique de la justesse non établie. Un avis automatique favorable ne devient pas une confiance élevée : cette limite reste visible avec la proposition, y compris après le rendu persona. Les refus et les contrôles de preuves restent contraignants. Cette transparence ne résout pas, à elle seule, les erreurs de fond du critique.
Prospection, support, mémoire, sécurité, architecture, docs, QA, data, decision brief, health-context et autres domaines ont des noms, routes et policies explicites.
Le rôle organisationnel, ses alias et sa persona sont distincts de l’agent technique choisi pour une mission. Un rôle peut proposer plusieurs capacités ; Elora doit en valider une exactement. Ni le nom lisible, ni la persona ne donnent une permission.
Chaque agent possède mandat, cycle d'exécution, artefacts requis, rubriques d'excellence, exemples gold standard, sorties inacceptables, anti-patterns, autorité déterministe, scénarios de mission et handoffs.
La commande elora-agent excellence vérifie que le contrat est sérieux avant usage opérationnel: mandat, cycle, artefacts, rubriques, exemples spécifiques, sorties inacceptables, autorité déterministe, scénarios, stop conditions, trace points et learning capture.
elora-agent review vérifie aussi l'alignement entre run et contrat: contrat présent, rubrique, artefacts, autorité déterministe, scénario, livrable, quality gate, limites et sortie inspectable. C'est un diagnostic sans mutation.
elora-agent eval relie chaque agent à des fixtures déterministes et vérifie scénarios, artefacts, preuves, signaux d'échec, rubric coverage et policy de mutation sans lancer de worker.
elora-harness vérifie qu'une mission concrète est câblable: agent prêt, scénario connu, playbook, inputs, evidence gate, pack Markdown, référence gold du même scénario, artefacts, quality gates et trace learning proposal-only. La couverture inclut maintenant vingt et un scénarios: des parcours pratiques disposant de scénarios E2E, la recherche publique locale, les chemins sécurité/décision operator-judgment et les spécialistes proposition/revue/curation. Le cockpit expose list/show/run/runs via sa console Harness, mais il ne lance pas le worker et ne devient pas l'autorité de readiness.
elora-trial classe les agents entre trial_ready et readiness_only, puis ajoute un coverage status: mapped_full_e2e, actionable_e2e_gap ou readiness_only_by_policy. Un parcours mappé est configuré pour un essai, pas déjà exécuté. Seul un résultat de run vérifié apporte une preuve locale sur son périmètre ; les contrats, la readiness et les résultats historiques restent séparés. Les anciens compteurs full_e2e_proven_count sont des alias de compatibilité du nombre de parcours mappés, pas un certificat du code courant. La recherche publique reste dans ce dernier groupe tant que la fraîcheur des sources et les claims du run n'ont pas passé la revue du résultat, même si son worker local est maintenant exécutable.
elora-agent operational fusionne inventaire agents, contrats Agent Excellence, fixtures eval, couverture elora-trial et Golden Paths. La sortie distingue mapped_full_e2e, readiness_only_by_policy, contract_ready_untrialed, setup_required et les gaps, puis expose safe_actions et next_safe_action par agent avec argv structuré. La console cockpit Agent Ops affiche ces actions via /api/agents/actions et peut lancer une action sûre par /api/agents/action-run avec seulement agent et action_id: le serveur relit la matrice, valide allowlist, type d'action, état sûr et flags non mutatifs, puis exécute la CLI déclarée. Aucun dispatch caché, aucune commande arbitraire navigateur, aucune mémoire, aucun routing, aucun provider ou contrat muté.
elora-agent reality vérifie ce que l'agent peut réellement faire: worker déterministe, overlay tool-backed, model-only, stub ou route non prête. Le dispatch persiste ce snapshot et bloque les claims local_code qui ne peuvent pas produire artefacts, fichiers et tests.
elora-capability fabrique des propositions de nouvelles capacités domaine: agent stub, playbook skeleton, inputs, artefacts, quality gates, readiness et promotion checklist. promote-plan transforme ensuite un pack validé en dossier de promotion reviewable avec patches candidats pour agent, playbook, compétence, excellence, fixture et harness. Le cockpit peut inspecter ces packs, valider et générer un dossier avec confirmation, mais rien n'est activé automatiquement: pas d'agent actif, pas de mutation mémoire, routing, providers ou config.
site_qualification_agent, docs_analysis_agent, docs_writer_agent, timeseries_forecast_agent et support_analyst_agent ont maintenant des chemins deterministic_worker: elora-site, elora-docs, elora-forecast et elora-support. Ils produisent des artefacts locaux inspectables avant tout handoff modèle, mémoire ou décision; docs_writer_agent produit un plan de mise à jour documentaire borné, et support_analyst_agent ne produit que des propositions de triage et brouillons AI-disclosed.
Les recherches publiques passent par web_research_brief, strategic_research_agent et le worker local_research. Elora lit d’abord les URLs fournies ; SearXNG et les alternatives configurées servent à découvrir d’autres sources. Un modèle local peut proposer une collecte complémentaire à partir de lacunes et de liens observés, sans inventer de cible ni prendre le contrôle des outils. Le corpus qualifié alimente une rédaction locale, puis une critique sur l’objectif, les sources, la profondeur, les incertitudes et l’utilité. Les révisions restent bornées et inspectables. Le brouillon déterministe est conservé ; une panne après rejet ne le transforme jamais en succès. Une limitation temporaire de recherche peut entraîner une attente persistée suivie d’une reprise dans le mandat initial. Ni le modèle, ni Hermes, ni une bonne note ne remplacent les preuves ou le jugement de l’opérateur.
elora-agent gold expose des exemples locaux de livrables excellents: forme attendue, barre qualité, extrait modèle et anti-patterns. Ces références guident revue et prompts futurs, mais ne prouvent pas qu'un run live est bon.
elora-context-files peut recommander, packer et gate des dossiers Markdown gouvernés. elora-playbook, elora-execute et elora-agent run --context-file transmettent ensuite statut, rôle, autorité, scope, provenance et contenu borné au worker comme contexte mission, pas comme vérité mémoire. Le prompt utilise wrapped_content sous ELORA_UNTRUSTED_CONTEXT; le Markdown peut guider, pas commander.
Chaque fixture déclare les rubriques du contrat qu'elle couvre. Si une rubrique manque, si la fixture invente un ID inconnu, si la fixture depth est trop faible ou si la multi-case fixture coverage manque sur un agent critique, l'agent n'est pas prêt pour un essai sérieux.
elora-agent scenarios expose des cas concrets par agent: objectifs, inputs requis, artefacts attendus, barre qualité, conditions de rejet, contrôles déterministes et policy de mutation.
Un worker peut terminer sans produire un livrable utilisable. Les gates déterministes, elora-result, la revue opérateur et le Result Acceptance Gate empêchent de confondre succès runtime et résultat accepté.
Aucun agent commercial, support ou prospection ne doit se faire passer pour un humain. Les brouillons externes appliquent la disclosure externe.
agent_run_log, quality_score, failure_reason, success_pattern, feedback résultat, propositions, playbooks, Execution Learning Bridge, Revision Review, pattern scores, learning trends, learning scorecard, promotion candidates avec preview/apply explicite, Learning Review Inbox, indexes learning et clarification learning events restent inspectables.
elora-playbook, le cockpit et Telegram permettent de préparer les missions récurrentes comme scaffolds locaux: inputs, mission, artefacts, checklist et commande d'enqueue, sans prétendre que l'agent a déjà exécuté.
elora-execute relie une next action à un plan, un scaffold playbook, un dispatch agent via queue, une sync, une review proposal-only, une synthèse livrable, une livraison finale, un Mission Outcome, une revision loop, une capture learning, une fermeture et un feedback résultat propagé si la queue existe. attach-worker ajoute le pont direct worker: un run lancé depuis le Worker Registry peut devenir une exécution direct_worker avec Result Acceptance, synthèse, livraison, feedback, outcome et close, sans relancer le worker ni promouvoir quoi que ce soit. Le Mission Supervisor peut appliquer les étapes déterministes sûres via le moteur auto-runner, mais s'arrête avant le jugement opérateur. La clôture normale done exige un livrable et un result contract acceptés, ainsi qu’un feedback explicite ou une dérogation auditée à ce feedback. Une clôture exceptionnelle malgré un résultat refusé exige séparément --allow-unaccepted-result --override-reason : elle ne transforme ni le refus en validation, ni la clôture en satisfaction opérateur.
elora-agent-traces importe des exports JSONL locaux de traces publiques, calcule stats, catégories et échantillons, extrait des patterns, puis génère des trace corpus proposals par agent. proposals review les classe en gates, playbooks, anti-patterns et gold examples. Aucun téléchargement automatique, aucune écriture mémoire, aucune mutation de routage.
elora-agent-improve transforme les signaux trace corpus et learning en patchs d'amélioration inspectables. Le cockpit expose review, propose, show, preview et apply avec confirmation exacte APPLY IMPROVEMENT. Telegram expose review/propose/preview mais refuse apply.
La boucle suit cinq étapes: review, feedback, preview, matérialisation, promotion. Les propositions ont des IDs inspectables avant promotion. Une inférence ne modifie pas implicitement mémoire, routage ou compétence.
elora-learning dans des index JSONL idempotents, passent par une inbox de revue opérateur, puis deviennent des propositions promotionnables, jamais des mutations cachées.
Exemples de lecture, avec valeurs illustratives : ces sorties statiques ne décrivent pas une installation en direct. Un résultat passed vaut pour le run concerné, pas pour tous les modèles ou toutes les versions.
brain@elora:~$ elora-agent doctor
total_agents: 33
enabled_agents: 32
domain_total: 22
domain_enabled: 21
ready_domain: 21
blocked_enabled_domain: 0
setup_required_disabled: stackx_discovery_agent
brain@elora:~$ elora-agent reality local_code_agent --task-class local_coding --requires-execution
status=ready
level=deterministic_worker
can_execute=true
can_write_files=true
can_run_tests=true
claim_policy=command_trace_required
brain@elora:~$ elora-agent reality docs_analysis_agent --task-class docs_analysis --requires-execution
status=ready
level=deterministic_worker
can_execute=true
claim_policy=claims_are_candidates_until_promoted
brain@elora:~$ elora-agent reality timeseries_forecast_agent --task-class timeseries_forecast --requires-execution
status=ready
level=deterministic_worker
can_execute=true
claim_policy=forecasts_are_hypotheses_not_facts
brain@elora:~$ elora-agent reality prospecting_researcher
status=ready
level=deterministic_worker
can_execute=true
provider=local_prospect_worker
claim_policy=site_evidence_and_command_outputs_are_authoritative_missing_facts_stay_unknown
brain@elora:~$ elora-agent reality support_analyst_agent
status=ready
level=deterministic_worker
can_execute=true
provider=local_support_worker
worker=local_support
claim_policy=supplied_ticket_evidence_and_command_outputs_are_authoritative_missing_facts_stay_unknown
brain@elora:~$ elora-agent resolve prospecting
resolved_name=prospecting_researcher
display_name=Prospecting Researcher
matched=prospecting
role=prospecting-researcher
brain@elora:~$ elora-agent excellence
total: 21
ready: 21
needs_hardening: 0
brain@elora:~$ elora-agent eval
ok=true
total=21
ready=21
needs_work=0
missing_fixtures=
average_score=100
prospecting_researcher | score=100 | ready=true | rubric_coverage=11/11
docs_analysis_agent | score=100 | ready=true | rubric_coverage=5/5
timeseries_forecast_agent | score=100 | ready=true | rubric_coverage=5/5
brain@elora:~$ elora-agent eval prospecting_researcher
ready=true
cases=2/2
rubric_coverage=11/11
fixture_depth=ok
rubric_missing=
brain@elora:~$ elora-harness run stackx_prospecting_harness
status=ready
score=100
mode=deterministic_mission_readiness_no_worker_launch
worker_launch=false
learning=proposal-only when --write
brain@elora:~$ elora-trial run stackx_prospecting_trial
status=passed
coverage_status=mapped_full_e2e
execution_proven=true
e2e_scenario=stackx_prospecting_local
worker=local_prospect
sending=false
brain@elora:~$ elora-harness run security_advisory_harness
status=ready
agent=security_analyst_agent
gold_reference=mitigation_script_review
side_effects=false
brain@elora:~$ elora-harness run documentation_update_harness
status=ready
agent=docs_writer_agent
gold_reference=operator_doc_update
site_impact_checked=true
brain@elora:~$ elora-trial doctor
trials=21
ready=21
full_e2e=7
readiness_only=14
actionable_e2e_gaps=0
readiness_only_by_policy=14
blocked=0
brain@elora:~$ elora-agent operational
total=21
mapped_full_e2e=7
readiness_only_by_policy=13
contract_ready_untrialed=0
setup_required=1
mutation=read_only_no_worker_no_memory_no_routing_no_provider_no_policy_mutation
brain@elora:~$ elora-trial run site_content_analysis_trial
status=passed
trial_ready=true
readiness_ready=true
execution_proven=true
brain@elora:~$ elora-trial run security_advisory_trial
status=readiness_only
coverage_status=readiness_only_by_policy
trial_ready=false
readiness_ready=true
execution_proven=false
gap=analysis-only path, no isolated execution proof
brain@elora:~$ elora-agent scenarios
total: 21
scenario_ready: 21
missing_scenarios: 0
missing_deterministic_authority: 0
brain@elora:~$ elora-agent gold prospecting_researcher
ready=true
gold=1/1
scenario_mapping=true
critical_missing=
brain@elora:~$ elora-learning indexes
agent_run_log.jsonl
agent_quality_score.jsonl
agent_failure_reason.jsonl
agent_success_pattern.jsonl
agent_playbook_entries.jsonl
operator_feedback.jsonl
memory_proposals.jsonl
routing_adjustments.jsonl
brain@elora:~$ elora-agent-traces source
source: lambda/hermes-agent-reasoning-traces
rows: 14701 | size: 1.62 GB
mode: explicit local import only
policy: proposal_only_no_memory_write
brain@elora:~$ elora-agent-traces propose --write
proposals: per-agent Agent Excellence review records
index: ELORA_DATA_DIR/agents/learning/indexes/trace_corpus_proposals.jsonl
mutation: none
brain@elora:~$ elora-agent-traces proposals review --agent architecture_agent --write
review_items: candidate_gate, candidate_playbook, candidate_anti_pattern, candidate_gold_example
artifact: ELORA_DATA_DIR/agent-traces/reviews/trace-review-*.json
mutation: none
brain@elora:~$ elora-agent-improve propose-patch --agent architecture_agent --source trace --write
patch: ELORA_DATA_DIR/agents/improvement/patches/improve-*.json
apply_default: dry-run
mutation: none
brain@elora:~$ elora-agent-improve apply PATCH_ID --apply
target: Agent Excellence overlay
mode: append-only, deduplicated, audited
canonical_memory_write: false
routing_mutation: false
brain@elora:~$ cockpit Improve
review: agents + patches
apply: requires APPLY IMPROVEMENT
brain@elora:~$ telegram /improve preview PATCH_ID
mode: dry-run only
apply: refused
brain@elora:~$ elora-agent excellence architecture_agent
trace_corpus_proposals: read-only context
mutation: none