Agents nommés
Prospection, support, mémoire, sécurité, architecture, docs, QA, data, decision brief, health-context et autres domaines ont des noms, routes et policies explicites.
domain_agents
Un agent routable ne suffit pas.
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. Une capacité déclarée reste soumise à sa readiness et à la vérification du résultat ; elle ne définit pas encore les futurs rôles métier de Christophe.
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.
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.
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.
Identity layer
Les agents peuvent avoir un display_name, des alias et plus tard des codenames reconnaissables dans l'univers de Christophe. Cette couche reste ergonomique: l'ID technique demeure l'autorité pour routing, policy, queue, learning et audit.
Contrats de compétence
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.
Agent Excellence
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.
Agent contract gate
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.
Evaluation harness
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.
Agent mission harness
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.
Agent operational trials
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.
Agent Operational Matrix
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é.
Worker Reality Gate
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.
Capability Factory
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.
Local worker capability pack
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.
Web research brief
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.
Gold output references
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.
Markdown mission packs
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.
Domain rubric harness
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.
Scénarios de mission
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.
Quality gates
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é.
Disclosure externe
Aucun agent commercial, support ou prospection ne doit se faire passer pour un humain. Les brouillons externes appliquent la disclosure externe.
Learning loop
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.
Playbooks domaine
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é.
Execution Handoff
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.
Agent trace corpus
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.
Improvement Workbench
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.
Promotion explicite
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