Juin 2026

Juin démarre par le passage des Golden Path Missions de l'état simplement mappé à l'état prouvé localement. Le point important n'est pas cosmétique: Elora distingue désormais ce qu'elle sait cadrer, ce qu'elle sait vérifier en readiness-only, et ce qu'elle a réellement exécuté en full E2E local.

Jalons

• Golden Path Certification Run 2026-06-01: elora-execute certify-golden-paths --apply --include-e2e --ready-paths-only --json a certifié sept chemins prêts: analyse de site, prospection StackX, analyse documentaire, mise à jour documentation, code local, forecast séries temporelles et support ticket triage. Chaque chemin possède un run elora-trial full E2E passed avec execution_proven=true.
• Support Ticket Triage Worker Bridge V1: support_ticket_triage passe de gap actionnable à chemin certifié grâce à local_support_worker / ./bin/elora-support. Le worker lit seulement des preuves fournies, produit classification, gaps, next actions et brouillon client avec disclosure IA, sans envoyer de message ni muter un ticket.
• Cockpit Support Triage Integration V1: le cockpit expose maintenant une console Support dédiée via POST /api/support/triage. Christophe peut coller un ticket, un contexte et une procédure éventuelle; le cockpit appelle le worker local, affiche le rapport, la qualité et le brouillon IA, mais ne contacte personne, ne mute aucun ticket et n'écrit pas la mémoire.
• Cockpit Worker Registry / Capability Launcher V1: le cockpit expose /api/workers, /api/worker et /api/worker/run. Les workers locaux queue-compatibles elora-site, elora-docs, elora-code, elora-forecast, elora-prospect et elora-support deviennent lançables depuis une console commune. elora-scrapegraph est listé comme capacité directe, mais reste hors launcher générique V1. Le cockpit affiche readiness, policy, résultat, qualité et artefacts sans posséder l'autorité.
• Worker Execution Lifecycle V2: chaque run direct du Worker Registry conserve désormais un lifecycle local avec preflight gate, result contract, quality gate, learning hint, fichiers d'audit et feedback opérateur proposal-only. Le cockpit peut relire /api/worker/lifecycle et enregistrer un feedback uniquement avec confirmation APPLY WORKER FEEDBACK, sans mémoire canonique, sans routing mutation et sans promotion automatique.
• Worker Result Contract Normalization V1: les workers directs écrivent désormais un result.json normalisé avec payload natif conservé, native_result, deliverable validable par elora-result, result.md, quality.json, manifest et snapshots natifs sous artifacts/. Un run direct peut donc être affiché safe seulement si le contrat de résultat passe réellement.
• Worker-to-Mission Bridge V1: un run direct lancé depuis le Worker Registry peut maintenant être attaché au lifecycle elora-execute via attach-worker ou /api/worker/attach. L'exécution direct_worker conserve le lifecycle, le résultat normalisé, le Result Acceptance Gate et la prochaine action sûre, puis peut passer par synthèse, livraison, feedback, outcome et fermeture sans relancer le worker ni muter mémoire/routing/provider.
• V0 Operational Acceleration: après ATTACH WORKER, le cockpit charge maintenant l'exécution direct_worker créée et expose les raccourcis de suite, sans contourner les gates elora-execute. La Readiness Matrix expose aussi cockpit_direct_status pour distinguer un daemon arrêté d'un chemin local cockpit/CLI encore utilisable. Les sources readiness sont parallélisées et bornées par timeout pour éviter qu'un doctor lent gèle l'interface.
• État après certification: elora-execute golden-pilots --json rapporte runtime_e2e_proven=7, certified=7, ready_to_certify=0, certification_gaps=0. security_advisory_response et decision_brief restent readiness-only par policy car ils exigent un jugement opérateur.
• Preuves et audit: les fichiers runtime restent dans sx-core-blueprint-kit/var/agents/trials/runs/, volontairement hors Git. Le snapshot suivi côté repository est documenté dans sx-core-blueprint-kit/docs/GOLDEN_PATH_CERTIFICATION_STATUS.md.
• Conséquence opératoire: Elora peut maintenant afficher clairement les chemins certifiés dans le cockpit et éviter de confondre "je sais router cette mission" avec "j'ai prouvé que ce chemin local complet fonctionne".