Mai 2026

Mai 2026 consolide le passage de la preuve de concept à un système opératoire: Mission Control, Strategic Operating Loop, Mission Execution Core, Guided Mission Runner, Mission Execution Loop, Mission Lifecycle Board, Sequence Execution Bridge, Distributional Exploration Gate, Execution Handoff, Mission Deliverable Synthesizer, Mission Delivery Loop, Mission Outcome, Mission Auto-Runner, Next Safe Action, Result Acceptance Gate, Claim Verification Gate, Execution Learning Bridge, Learning Review Inbox, Control Plane cockpit, Worker Reality Gate, Operator Flow V2, daily operating core, intuition pipeline, attention guard, operator-state, domain playbooks, agents nommés, agent identity layer, contrats de compétence, Agent Excellence, domain rubric harness, Agent Mission Harness, Mission E2E, Mission Live Run, Mission Operations, fixture depth, multi-case fixture coverage, gold output references, agent trace corpus, learning proposals, miroir Markdown Memory V2, Markdown mission packs, timeseries.forecast, extraction sémantique locale et site statique dédié.

Jalons

• Daily operating core: ajout de elora-ops et des wrappers elora-projects, elora-open-loops, elora-decisions, elora-next et elora-brief pour maintenir projets actifs, fils ouverts, décisions opérateur et prochaines actions en JSON local auditable.
• Mission Control: ajout de elora-operate pour agréger operator-core, attention guard, operator-state, domain playbooks et agent readiness en brief, triage, next step, plan-day et handoff déterministe sans modèle ni worker caché.
• Strategic Operating Loop V1: ajout de elora-strategy pour produire un brief stratégique, trier un signal texte, proposer une séquence exécutable et générer une review de cycle au-dessus de Mission Control et du pipeline intuition, sans modèle, worker caché, mémoire canonique ou mutation routing.
• Mission cockpit: exposition de Mission Control dans le cockpit local avec brief, triage, next, plan-day, preview de handoff et confirmation APPLY HANDOFF; le panneau reste une surface et ne fait que déléguer à elora-operate.
• Mission Execution Core V1: ajout de elora-execute mission, POST /api/execution/mission et Mission libre dans le cockpit pour transformer une mission opérateur en next action virtuelle, plan Execution Handoff, start réel et dispatch optionnel. Preview ne mute rien; start exige START MISSION, start + dispatch exige DISPATCH MISSION, et les inputs manquants deviennent des questions de clarification précises.
• Mission Execution Reliability V2: elora-execute mission et elora-execute plan exposent maintenant mission_readiness: statut safe, warning ou blocked, possibilité de start/dispatch, raison de route, agent primaire, worker reality, inputs manquants, questions de clarification, artefacts attendus, quality gates et prochaine action recommandée. Le cockpit affiche cette synthèse avant le JSON brut.
• Mission E2E Reliability V1: ajout de elora-e2e pour vérifier dans un data root temporaire les chemins locaux complets: mission, dispatch, sxcore run-once, worker déterministe, result contract, sync, review, learning preview, feedback preview et close readiness. Les scénarios V1 couvrent analyse de site locale, analyse documentaire, forecast local et code Hello World, sans Telegram, Hermes, Codex, provider distant, mémoire canonique ou mutation routing.
• Cockpit Mission Reliability Console V1: le cockpit expose maintenant GET /api/e2e et POST /api/e2e/run pour lire les scénarios elora-e2e, vérifier le doctor, lancer un scénario ou tous les scénarios, afficher phases, acceptance gate, fichiers produits, erreurs et mutation policy sans calculer lui-même la fiabilité ni accepter de commande arbitraire.
• Mission Live Run V1: ajout de elora-live-run et de la console cockpit Live. Le runner démarre un cockpit loopback isolé, extrait le token local, vérifie refus auth et confirmation, traverse les APIs cockpit, lance sxcore run-once, puis sync, review, synthèse, livraison, feedback, outcome, learning et close avec les confirmations exactes. Il mesure la friction opérateur et prouve le chemin cockpit sans Telegram, Hermes, Codex, provider distant, mémoire canonique ou mutation routing.
• Mission Operations V1: elora-live-run expose maintenant un contrat mission_operations lisible par opérateur avec compris, contexte, routing, gates, état safe/warning/blocked, timeline, artefacts, blockers et prochaines actions. Le cockpit l'affiche au-dessus des traces brutes sans devenir l'autorité.
• Mission Router / Composer V2: elora-execute mission --playbook PLAYBOOK_ID permet de forcer un playbook connu sans perdre l'auto-routing. Le choix est exposé par route.selection_source, persisté comme marqueur inspectable playbook:<id>, et disponible dans le cockpit via un sélecteur Auto/playbook; les inputs requis, Mission readiness, gates evidence et confirmations restent obligatoires.
• Mission Clarification / Composition V2: elora-execute mission --context-json ajoute un Mission preflight inspectable avec texte original, texte effectif, inputs détectés, manquants avant/après composition et hypothèses. Le cockpit transmet les derniers messages de la session active; Elora peut réutiliser une URL ou un domaine évident pour remplir url ou target_url_or_domain, puis bloque encore si le contexte reste insuffisant. La composition est déterministe, bornée, ne lance pas de worker, ne mute pas la mémoire et ne contourne aucun gate.
• Pending Mission Clarification Resolver V1: quand une mission libre appliquée atteint encore needs_input, Elora écrit une pending mission sous execution-handoff/pending-missions/. elora-execute pending, pending-show et clarify permettent d'inspecter, répondre, prévisualiser, appliquer ou appliquer+dispatcher en repassant par Mission preflight, Mission readiness, evidence gates, confirmations et audit. Le cockpit affiche désormais ce brouillon et sa résolution dans Mission libre.
• Mission Lifecycle Board V1: ajout de elora-execute board, /api/execution/board et d'une vue cockpit en lanes read-only pour pending missions, exécutions, queue, review, result acceptance, feedback, outcome, learning et Next Safe Action.
• Mission Lifecycle Actions V1: le board expose maintenant des available_actions par item et le cockpit appelle /api/execution/board/action, une allowlist stricte vers les contrats CLI existants. Les mutations gardent les confirmations START MISSION, DISPATCH MISSION, DISPATCH EXECUTION, REQUEST REVISION, CAPTURE LEARNING, APPLY FEEDBACK ou CLOSE EXECUTION.
• Guided Mission Runner V1: ajout de elora-execute cycle, /api/execution/cycle et d'un panneau cockpit guidé pour assembler mission libre, exécution, evidence, Result Acceptance et Next Safe Action en une étape lisible. Le cycle reste déterministe: pas de modèle, pas de dispatch caché, pas de clôture automatique, pas de promotion learning et aucune mutation mémoire/routing/provider.
• Mission Execution Loop V1: ajout de elora-execute loop, /api/execution/loop et d'un panneau cockpit qui choisit un focus depuis le board par lane, sévérité et récence, puis propose une action existante sans mutation cachée.
• Mission Execution Loop V2: ajout de mission_timeline et gate_summary dans elora-execute loop. Le cockpit peut maintenant montrer intake, evidence/context, dispatch, résultat/vérification, acceptance et learning/closure, plus l'état des gates, avant toute action explicite.
• Mission Workbench Actionability V1: la timeline, le résumé des gates et la carte focus peuvent maintenant afficher les actions existantes du board directement dans le Workbench. Chaque bouton reste dérivé de focus_item.available_actions et passe par /api/execution/board/action avec les confirmations CLI existantes.
• Mission Workbench Operator Runbook V1: elora-execute loop expose maintenant un runbook opérateur CLI-owned. Le Workbench affiche action courante, classification safe/dry-run/confirmation/jugement/blocked, inputs requis, résultat attendu, étapes de mission et règles de refresh sans inventer d'action ni transférer l'autorité au navigateur.
• Golden Path Missions V1: elora-execute golden-paths expose un catalogue déterministe read-only de missions standard reliées aux playbooks et trials: analyse site, prospection StackX, analyse documentaire, documentation, code local, forecast, support, sécurité et decision brief. Le cockpit lit /api/execution/golden-paths, affiche statut ready/degraded/judgment_required/blocked, inputs, artefacts, gates et policy, puis préremplit Mission libre sans démarrer worker, dispatcher, muter mémoire ou contourner les confirmations.
• Golden Path Runner V1/V2: elora-execute golden-run transforme une Golden Path Mission en action structurée avec schema, questions de clarification, mission rendue, runner gate, dry-run et start via elora-execute cycle. Le cockpit rend maintenant des champs structurés par mission au lieu d'imposer une textarea JSON, conserve les exemples en placeholders non exécutables, puis affiche un panneau résultat lisible: gate, inputs manquants, questions utiles, mission rendue, artefacts attendus et policy avant le JSON brut. Un start appliqué attache golden_path_runner et golden-path-run.json à l'exécution; le dispatch direct reste limité aux chemins ready.
• Golden Path Operational Trials V1: elora-execute golden-pilots relie le catalogue Golden Path aux proofs elora-trial/elora-e2e. Le cockpit affiche désormais un badge proof par carte et un bouton Pilot qui lance un check readiness-only déterministe via /api/execution/golden-pilot, sans modèle, Hermes, Codex, Telegram, mémoire canonique, mutation routing ou provider.
• Golden Path Certification V1: elora-execute certify-golden-paths distingue les chemins prêts à certifier, readiness-only enregistrés et réellement certifiés par un run elora-trial full E2E local passed. Le cockpit affiche cert=..., peut prévisualiser les candidats, puis lancer la certification des chemins ready derrière confirmation CERTIFY GOLDEN PATHS. Les écritures restent limitées aux fichiers de run et learning proposals; aucune mémoire canonique, route, provider ou policy n'est mutée.
• Core Operational Readiness V1: elora-readiness matrix --json expose maintenant operational_core_status et un check mission_runtime. Il vérifie board/loop, evidence, verification, inventaire E2E, inventaire trials, queue, agents, playbooks et harnesses sans lancer E2E, trial, worker, modèle, mémoire ou mutation routing. Le cockpit affiche ce statut dans Readiness et Operator Flow.
• Agent Trial Coverage Policy V1: elora-trial expose maintenant coverage_status, e2e_policy et e2e_gap_actionable. Les trials se séparent entre full_e2e_proven, actionable_e2e_gap et readiness_only_by_policy. La readiness mission runtime avertit sur les gaps E2E réellement actionnables, sans transformer sécurité ou decision brief en faux chemins d'exécution automatique.
• Documentation Update Worker Bridge V1: docs_writer_agent passe sur le worker local elora-docs pour produire doc_update_plan.md, changed_files.md, validation_notes.md et journal_entry.md sans Hermes, Codex, mutation repo ou écriture mémoire. documentation_update_trial devient full E2E-proven; les gaps actionnables passent de trois à deux.
• Execution Handoff: ajout de elora-execute pour transformer une next action en plan inspectable, démarrer un scaffold playbook borné quand les inputs sont complets, dispatcher explicitement l'agent primaire via la queue Elora, synchroniser l'état worker, attacher une review proposal-only, capturer le learning, fermer l'exécution et enregistrer le feedback sans modèle caché, commande arbitraire, action externe ou mutation mémoire/routing.
• Mission Deliverable Synthesizer V1: ajout de elora-execute synthesize, /api/execution/synthesis et /api/execution/synthesize pour produire une synthèse livrable extractive: faits, assessment, limites, recommandations, evidence, excerpt, artefacts et prochaine action depuis les records existants. Preview ne mute rien; save exige SAVE SYNTHESIS et écrit seulement synthesis.json et .deliverable_synthesis.
• Mission Delivery Loop + Auto-Runner V1: ajout de elora-execute deliver, /api/execution/delivery, /api/execution/deliver, elora-execute autorun et /api/execution/autorun. La livraison finale exige une synthèse courante et un résultat accepté, puis écrit seulement delivery.json, .final_delivery et .files.delivery après confirmation SAVE DELIVERY. L'auto-runner avance uniquement sync/review/synthèse/livraison quand les gates sont sûrs, demande RUN AUTORUN en apply, et s'arrête avant outcome, dispatch, feedback, learning, révision, clarification ou clôture.
• Mission Outcome / Operator Review Flow V1: ajout de elora-execute outcome, /api/execution/outcome, boutons cockpit Preview issue / Save issue, action board outcome_preview / outcome_apply et confirmation SAVE OUTCOME. L'issue opérateur écrit mission_outcome.json, .mission_outcome et .files.mission_outcome après livraison finale et feedback, puis guide learning/close sans muter mémoire, routing, provider, policy ou contrats agents. close --outcome done exige maintenant un feedback explicite ou un override audité.
• Dispatch Context Gate V1: elora-playbook start et elora-execute start stockent le snapshot evidence_gate_snapshot, context_quality et les questions de clarification; elora-execute dispatch bloque les contextes blocked sauf raison d'override explicite, puis conserve le snapshot avec l'exécution et la queue pour audit.
• Result Acceptance Gate V1: elora-execute sync et elora-execute review stockent result_acceptance; elora-execute close --outcome done bloque les résultats non acceptés sauf override opérateur explicite avec raison auditée. Le cockpit affiche le statut d'acceptation et impose le même chemin.
• Claim Verification Gate V1: ajout de elora-verify pour extraire les affirmations d'un livrable, générer des questions de vérification ouvertes, vérifier uniquement des preuves indépendantes fournies, cross-checker le brouillon et stocker un snapshot advisory/blocking dans result_acceptance.evidence.claim_verification, sans modèle, worker, mutation mémoire ou mutation routing.
• Cockpit Result Verification Console V1: ajout de POST /api/result/verify, d'une console Verification et de boutons Claims sur les vues Execution, Resultat et Queue. Le cockpit relance elora-verify inspect avec preuve temporaire optionnelle, affiche snapshot, claims, questions et actions requises, mais n'accepte pas le résultat et ne persiste pas cette preuve en mémoire.
• Cockpit Result Feedback / Learning Bridge V1: elora-execute feedback accepte maintenant une décision accepted, needs_revision, rejected ou comment, stocke un snapshot result_feedback avec contexte de résultat et propage le signal vers elora-learning feedback quand la queue existe. Le cockpit expose Accept result, Needs revision, Reject result et Preview comment derrière APPLY FEEDBACK; ce feedback résultat reste proposal-only et ne remplace pas Result Acceptance.
• Execution Outcome Router / Guided Next Action V1: ajout de elora-execute next-action, de .next_safe_action dans elora-execute show, de /api/execution/next-action et d'une carte cockpit Next Safe Action. Elora propose le prochain geste sûr depuis l'état réel de l'exécution: dispatch preview, sync, review, claims, feedback, outcome, learning, revision, close ou clarification, sans modèle, worker, queue mutation, mémoire ou routing.
• Result Contract Harness V1: ajout de elora-result pour valider localement les livrables worker: result.md, result.json, quality.json, manifeste artefacts, chemins réels, JSON valide, kinds obligatoires et statut qualité. sxqueue result --json expose result_contract, et result_acceptance conserve ce snapshot pour audit.
• Revision Loop V1: ajout de elora-execute revise et /api/execution/revise pour transformer un résultat failed, contract_violation ou needs_revision en demande de correction explicite. La boucle écrit un prompt de révision, patche la queue, repasse l'item en pending et conserve la raison opérateur dans l'audit sans accepter le mauvais résultat.
• Execution Attempt Ledger V1: avant qu'une révision remette la queue en pending, Elora écrit attempts/attempt-*.json et attempts/attempt-*.queue.json pour préserver l'état terminal, le result_acceptance, le result_contract, les artefacts et l'erreur précédente.
• Execution Attempt Comparison V1: ajout de elora-execute compare et /api/execution/compare pour comparer la dernière tentative capturée au résultat courant: current_not_terminal, improved, regressed ou unchanged, sans promotion learning automatique.
• Revision Learning Bridge V1: elora-execute learn --apply peut maintenant transformer une comparaison de tentative prête en item execution_revision_comparison reviewable dans les index learning, sans mutation mémoire, routing, provider ou contrat agent.
• Revision Review Report V1: ajout de elora-learning revision-review et d'un panneau cockpit Learning pour agréger les comparaisons de révision improved, regressed et unchanged, avec statuts d'inbox et actions de revue opérateur.
• Learning Promotion Candidates V1: ajout de elora-learning promotion-candidates et d'un panneau cockpit Learning pour regrouper les items learning revus/acceptés en décisions de promotion explicites, sans application automatique.
• Learning Promotion Workbench V1: le cockpit peut maintenant prévisualiser et appliquer une promotion directe via POST /api/learning/promote, avec confirmation explicite PROMOTE LEARNING et sans mutation implicite de mémoire, routing, provider ou contrat agent.
• Learning Pattern Scores V1: ajout de elora-learning pattern-scores et d'un panneau cockpit Learning pour classer les signaux répétés par score déterministe, qualité, statuts, rejets et potentiel de promotion, sans mutation automatique.
• Learning Trend History V1: ajout de elora-learning trends et d'un panneau cockpit Learning pour suivre qualité, feedback opérateur, direction, risque et score ajusté par agent/task class, sans mutation de routing ou contrat agent.
• Learning Operator Scorecard V1: ajout de elora-learning scorecard et d'un panneau cockpit Learning pour prioriser l'attention opérateur par agent à partir de la readiness d'excellence, des tendances, du feedback et de l'inbox, sans confiance ou mutation automatique.
• Agent Contract Review Gate V1: elora-agent review expose maintenant un agent contract gate déterministe pour vérifier l'alignement entre run, contrat de compétence, livrable, quality gate, preuves et autorité déterministe.
• Execution Learning Bridge: ajout de elora-execute learn et /api/execution/learn pour matérialiser les artefacts elora-learning depuis une exécution queue-backed, stocker .learning dans le record, capturer la comparaison de révision quand elle est prête, et propager le feedback opérateur vers elora-learning feedback quand la queue existe. Le cockpit exige CAPTURE LEARNING pour appliquer.
• Learning Review Inbox: ajout de elora-learning inbox, inbox-show et inbox-mark, plus une console cockpit Learning, pour trier les signaux learning en new, reviewed, accepted, rejected, snoozed ou promoted sans mutation implicite de mémoire, routing, provider ou contrat agent.
• Execution cockpit: exposition de elora-execute dans le cockpit local avec plan/start/dispatch/sync/review/learn/list/show/close/feedback; les cartes affichent l'état safe, safe_with_warnings ou blocked, et les applications réelles exigent START EXECUTION, DISPATCH EXECUTION, CAPTURE LEARNING, CLOSE EXECUTION ou APPLY FEEDBACK.
• Sequence Execution Bridge: ajout de elora-execute sequence et de /api/intake/execute pour transformer une séquence persistée en execution handoff, créer la next action manquante si nécessaire, et dispatcher explicitement après confirmation EXECUTE SEQUENCE.
• Distributional Exploration Gate V1: ajout de elora-explore pour décider quand une exploration multi-options est utile, générer un prompt Verbalized Exploration Operator, produire ou valider des candidate sets proposal-only, et distinguer estimated_typicality d'une probabilité objective.
• Semantic Collision Exploration V1: extension de elora-explore avec domain-bank, collide et validate-collisions. Elora peut maintenant générer des collision candidates à partir de domaines structurellement distants, tout en gardant preuves, checks déterministes, policy et revue opérateur comme autorité.
• Exploration Integration V1: les playbooks et exécutions conservent maintenant un snapshot d'exploration, elora-execute explore EXECUTION_ID --kind collision|candidates --dry-run --json produit des previews proposal-only depuis le contexte d'exécution, et le cockpit expose Explore collision / Explore options sans dispatch, mémoire, routing ou provider mutation.
• Prompt Boundary Reinforcement V1: ajout d'un contrat final Elora-owned aux prompts model-backed pour renforcer les invariants sûrs sans répéter le texte utilisateur, les sources brutes ou les contenus non fiables.
• Operator Flow V2: ajout d'une console cockpit par défaut qui agrège Work Intake, Mission Control, Execution Handoff, queue, playbooks, review, learning capture, feedback et Improve pour montrer le travail actif et le prochain geste sûr sans posséder mémoire, policy, routing ou autorité.
• Control Plane cockpit: ajout d'une console Control read-only qui agrège eloractl status --json et eloractl doctor --json dans le cockpit pour inspecter process, queue, approvals, mémoire, provider, agent, commandes, fichiers et chemins sans mutation de mémoire, policy, routing, provider ou worker.
• Readiness Matrix V1: ajout de elora-readiness matrix --json et d'une console cockpit Readiness pour normaliser control plane, commandes, providers, agents, Agent Excellence, playbooks, harnesses, context files et queue en ready, warning ou blocked, sans modèle, worker ou mutation.
• Worker Reality Gate V1: ajout de elora-agent reality, exposition dans elora-agent show/doctor, synthèse dans elora-readiness, persistance execution.worker_reality dans la queue et blocage des chemins local_coding qui ne sont pas des workers déterministes capables de produire artefacts, fichiers bornés et tests.
• Local Worker Capability Pack V1: ajout de elora-site, elora-docs et elora-forecast comme workers déterministes queue-compatible pour analyse de site, analyse documentaire et forecast local. Les agents site_qualification_agent, docs_analysis_agent et timeseries_forecast_agent ont maintenant providers, contrats, fixtures, harnesses et artefacts inspectables.
• Local Worker Artifact Preservation V1: les workers locaux conservent leurs sorties structurées natives sous artifacts/native_result.json et artifacts/native_quality.json. sxqueue result fusionne maintenant les artefacts sûrs du manifeste worker dans le contrat de résultat final, sans les remplacer par une simple synthèse.
• Cockpit Result Artifact Inspector V1: le cockpit ouvre maintenant les artefacts référencés par sxqueue result en lecture seule, par queue id et index de livrable. Les sorties natives JSON/qualité des workers locaux deviennent consultables depuis la surface opérateur sans transformer le cockpit en navigateur de fichiers ni lui donner autorité sur mémoire, routing, providers ou queue.
• Result Artifact CLI Contract V1: elora-result artifact --queue-id ID --index N --json devient le contrat déterministe pour inspecter un artefact résultat référencé. Le cockpit délègue à ce CLI au lieu de posséder la logique d'accès aux fichiers.
• Intuition pipeline: ajout de elora-intuitions et elora-sequences pour capturer une intuition brute, lister objectifs, contraintes, hypothèses, risques, agents/outils suggérés, artefacts et critères de succès, puis générer une séquence exécutable locale avec première next action optionnelle.
• Work Intake cockpit: ajout d'une console Intake qui expose le pipeline d'intuition dans le cockpit avec preview, confirmation CAPTURE INTUITION, confirmation CREATE SEQUENCE, historique et inspection JSON sans écrire la mémoire ni lancer de modèle.
• Attention guard: ajout de elora-attention pour maintenir focus windows, sujets not-now, demandes entrantes, triage local interrupt/allow/defer/not_now, brief d'attention, dry-run et création explicite de next action seulement quand le triage le justifie.
• Operator-state: ajout de elora-operator-state pour exposer check-ins, énergie, fatigue, charge, disponibilité, contexte santé non médical, contraintes, engagements et brief de soutenabilité sans écrire dans Memory V2.
• Domain playbooks: ajout de elora-playbook et d'un registre local pour cadrer StackX prospecting, analyse site, support, sécurité, documentation, décision, code local et forecast avec inputs requis, artefacts, handoffs, quality gates, dry-run et aucun side effect.
• Playbooks cockpit/Telegram: exposition des mêmes playbooks par le cockpit local et les commandes Telegram /playbooks, /playbook ID, /playbook preview et /playbook start, toujours comme scaffolds CLI-backed sans lancement automatique de worker.
• Agents: extension du roster aux domaines stratégie, sécurité, architecture, docs, QA, ops, data, decision et health-context.
• Agent Identity Layer V1: ajout de etc/elora/agent_identity.json et de elora-agent resolve pour exposer noms lisibles, alias et futurs codenames sans modifier les IDs techniques, routes, policies, queues, learning ou audits.
• Compétence: mandats, rubriques, artefacts requis, anti-patterns et handoffs.
• Agent Excellence: ajout d'un contrôle déterministe des contrats agents avant usage sérieux: mandat, cycle, artefacts, rubriques, exemples gold standard, sorties inacceptables, autorité déterministe, scénarios, stop conditions, trace points et learning capture.
• Evaluation harness: ajout de elora-agent eval et de fixtures déterministes pour vérifier que chaque agent activé possède au moins un scénario représentatif, des artefacts attendus, des preuves exigées, des signaux d'échec et une policy sans mutation implicite.
• Domain Rubric Harness V1: elora-agent eval expose maintenant rubric_coverage. Les fixtures doivent couvrir explicitement toutes les rubriques du contrat agent; rubriques manquantes ou inconnues bloquent readiness sans lancer de worker.
• Agent Fixture Corpus V1: elora-agent eval exige maintenant une fixture depth minimale par cas: au moins trois gold_checks et deux artifact_assertions. Une fixture trop nominale échoue via fixture_depth_declared, même si les rubriques sont couvertes.
• Critical Agent Multi-Case Eval V1: les agents critiques de prospection, qualification, code local, mémoire, support et revue de livrable exigent maintenant au moins deux scénarios locaux distincts. elora-agent eval bloque readiness via minimum_case_count si un seul cas nominal reste présent.
• Agent Gold Output Corpus V1: ajout de etc/elora/agent_gold_outputs.json et de elora-agent gold pour exposer des références locales de livrables excellents, mappées aux scénarios, sans worker, modèle, mutation mémoire, routing ou promotion implicite.
• Agent Mission Harness V1/V2: ajout de elora-harness et de scénarios mission readiness pour StackX prospecting, analyse site, support, code local, sécurité, documentation, decision brief, forecast et analyse document. Le harness vérifie agent, playbook, inputs, gates, artefacts et learning traces sans lancer de worker; --write produit seulement des items proposal-only dans les index learning. Les chemins sécurité et documentation ont maintenant des références gold mappées, car un faux positif dans ces domaines coûte cher à l'opérateur.
• Cockpit Agent Harness Integration V1: ajout d'une console Harness dans le cockpit. Elle liste les scénarios, affiche un scénario, lance un diagnostic dry-run et écrit une trace proposal-only via elora-harness, sans lancer de worker ni déplacer l'autorité hors des CLI.
• Agent Operational Trials V1: ajout de elora-trial, du registre agent_operational_trials.json et d'une console cockpit Trials pour distinguer les chemins trial_ready avec preuve E2E locale isolée des chemins readiness_only seulement prouvés par harness. V1 couvre neuf essais et distingue maintenant six chemins full E2E-proven, un gap actionnable et deux chemins readiness-only par policy, sans modèle, Telegram, Hermes, Codex, provider distant, mémoire canonique ou mutation routing.
• StackX Prospecting Worker Bridge V1: ajout de elora-prospect et du provider local_prospect_worker. prospecting_researcher produit désormais localement lead_report.md, target_inventory.json, site_qualification.json, contact_candidates.json, outreach_draft.md avec disclosure IA et review_report.md. stackx_prospecting_trial passe full E2E-proven; support triage reste le seul gap worker actionnable.
• Agent trace corpus: ajout de elora-agent-traces pour importer localement des exports JSONL de traces publiques, calculer stats/catégories/échantillons, extraire des propositions de patterns, générer des trace corpus proposals par agent et les classer via trace corpus review sans téléchargement automatique, sans mémoire canonique et sans mutation de routing.
• Agent Improvement Workbench: ajout de elora-agent-improve pour transformer les propositions trace/learning en improvement patches inspectables, dry-run par défaut, applicables seulement avec --apply, cible verrouillée sur l'overlay Agent Excellence configuré, sauvegarde, audit, verrou local et validation.
• Improvement cockpit/Telegram: exposition du workbench agents dans le cockpit avec review/propose/show/preview/apply confirmé par APPLY IMPROVEMENT, et dans Telegram avec /improvements, /improve AGENT, /improve propose, /improve patch et /improve preview. Telegram refuse l'application.
• Audit eval: durcissement du cas de fixtures absentes; l'évaluation échoue explicitement au lieu de produire un faux état globalement valide.
• Confiance externe: les agents ne se font pas passer pour des humains.
• Site: première version statique HTML/CSS pure, directement servable.
• Site CLI map: ajout de cli.html pour documenter publiquement les binaires locaux Elora, leur rôle et leur place dans l'architecture déterministe-first.
• Persona: clarification de la couche de rendu et de présence, séparée de mémoire, policies, tools et approvals.
• Mémoire: clarification publique du cycle capture, spool, canonicalisation, embeddings Ollama, retrieval et evidence pack.
• Evidence packs: formalisation du contrat L0/L1/L2/L3 dans elora-context, avec séparation explicite entre connu localement, inféré, manquant et à clarifier.
• Evidence Pack hardening: ajout d'un contrat de réponse facts/assessment/recommendations/hypotheses/unknowns/required_clarifications, d'une règle d'autorité déterministe dans le pack, et persistance de evidence_pack/evidence_context dans les playbooks et Execution Handoff.
• Evidence Inspector: ajout de elora-evidence inspect et de la console cockpit Evidence pour relire runs playbook, executions et queues avec quality gate, issues, warnings, recommandations, questions de clarification, L0/L1/L2/L3 et autorité déterministe, sans mutation de mémoire, routing, provider ou dispatch.
• Concept pages V1: ajout des pages approfondies pour control plane, autorité opérateur, déterministe d'abord, evidence packs, context quality gate, Mission Control, contrats agents, learning loop, providers locaux et playbooks, plus navigation déroulante progressive.
• Clarification: réduction des boucles de cadrage trop flou quand une URL, un repo local, une section ou un contexte récent fournit déjà une cible exploitable.
• local_code: durcissement du fallback code local sans Codex/Claude/Hermes, avec modèle local OpenAI-compatible optionnel, réponse brute provider, plan, manifest, validation log, code extrait et claims explicites sans mutation repo.
• OpenCode backend V1: ajout d'un backend client derrière elora-code pour comprendre/documenter un repo en read-only ou créer/modifier une application locale en mode édition borné, avec provider local OpenAI-compatible injecté depuis ELORA_LOCAL_CODE_*, prompt/stdout/stderr/résultat/run JSON, status Git, diff et fichiers changés conservés dans la session worker.
• Worker Execution Modes + Patch Acceptance Gate V1: elora-code expose maintenant read_only, bounded et trusted_free; les diffs OpenCode passent par elora-code patch inspect/decide pour enregistrer accepted, needs_revision ou rejected sans commit Git ni mutation mémoire/routing.
• Cockpit Patch Review local_code V1: le cockpit expose maintenant GET /api/code/patch et POST /api/code/patch/decide, wrappers stricts autour de elora-code patch inspect/decide. Les vues résultat, queue et exécution peuvent afficher diff borné, fichiers modifiés, gate patch_acceptance et formulaire de décision; l'enregistrement exige DECIDE PATCH et ne commit rien.
• Cockpit Operator Ergonomics V1: rééquilibrage du layout desktop pour donner plus de largeur à l'inspecteur, réduction de l'entassement des consoles par actions fréquentes visibles et groupes déroulants Diagnostics, Agents/tests et Admin. Le cockpit reste une surface CLI-backed sans autorité propre.
• Cockpit Mission Workbench V1: ajout d'une vue par défaut centrée mission. Elle rassemble focus elora-execute loop, lanes du board, route/playbook, agent/worker, evidence/context gate, queue, result acceptance, feedback/outcome/learning, prochaine action sûre et actions déclarées par les CLIs, avec auto-refresh borné et sans transfert d'autorité au navigateur.
• Cockpit Mission Workbench V2: remplacement des prompts lifecycle par une modale structurée affichant métadonnées d'action, champs requis, confirmation exacte et preview dry-run quand un équivalent CLI existe; ajout d'une timeline de mission en 7 étapes dans le Workbench.
• Providers: doctor JSON enrichi avec une synthèse plate pour cockpit, tests et administration locale.
• Learning loop: ajout d'une vue cinq étapes, d'IDs de propositions promotionnables et d'une promotion explicite, avec ledger local, promoted playbooks et aucune mutation cachée de mémoire, routing ou compétence.
• Miroir Markdown: export privé généré depuis PostgreSQL pour inspection, preuves, sauvegarde, relecture humaine et context packs, sans devenir mémoire canonique.
• Context Files / Markdown Mission Packs V2: elora-context-files peut recommander, packer et gate des dossiers Markdown vivants; elora-playbook, elora-execute, le dispatch queue, le cockpit et elora-agent run --context-file propagent le même pack advisory sans mutation de mémoire canonique.
• Forecasting local: intégration de TimesFM comme worker spécialisé timeseries.forecast, avec fallback déterministe, readiness explicite, artefacts et sorties marquées comme hypothèses.
• ScrapeGraphAI Local Semantic Extractor V1: ajout de elora-scrapegraph et de la capacité web.extract.semantic. Le chemin baseline déterministe structure le HTML pour les tests; le provider optionnel scrapegraphai_ollama utilise un venv local, Ollama et la télémétrie désactivée par défaut. Les sorties modèle restent des hypothèses vérifiables contre le snapshot source.
• Hermes v0.15: mise à jour de l'overlay Hermes, exposition de la version et du statut de mise à jour dans sxhermes doctor --json, et cadrage des nouvelles capacités Hermes comme opportunités de provider/worker. Security advisories, prompt-injection signals, skill curator, dashboard et Kanban restent optionnels et subordonnés à mémoire, policy, routing, approvals et gates qualité Elora.