scripts/test.sh --suite fast
Suite par défaut: syntaxe, bootstrap et smoke déterministe du control plane. C'est le chemin quotidien après un lot court.
operator interface
CLI et binaires Elora
Elora est CLI-first: chaque capacité critique doit exister comme commande locale inspectable avant d'être exposée par le cockpit, Telegram ou un agent. Cette page donne une carte synthétique des binaires actuels. La syntaxe exhaustive reste dans chaque commande via --help.
brain@elora:~$ find sx-core-blueprint-kit/bin -maxdepth 1 -type f | sort
control_plane: eloractl, elora-readiness, elora-policy, elora-router, elora-provider
mission_loop: elora-operate, elora-execute, elora-playbook, elora-harness, elora-trial, elora-e2e, elora-live-run
memory_context: elora-memory, elora-ingest, elora-retrieve, elora-context-files, elora-context-trust
agents_learning: elora-agent, elora-capability, elora-agent-improve, elora-learning, elora-agent-traces
local_capabilities: elora-models, elora-fetch, elora-search, elora-scrapegraph, elora-browser, elora-image, elora-vision, elora-tts
workers: elora-site, elora-docs, elora-code, elora-forecast, elora-prospect, elora-support
legacy_wrappers: sxqueue, sxapprove, sxhermes, sxcodex, sxmemoryvalidation
Suites de vérification locales
--suite runtime|cockpit|execution|agents|e2e
Suites ciblées pour vérifier un sous-système sans relancer la régression historique complète. Elles isolent runtime/providers, cockpit, handoff mission, contrats agents/harness et mission E2E locale.
--suite telegram / --suite full
Telegram est volontairement opt-in avec ELORA_TEST_TELEGRAM=1. full conserve le chemin monolithique long pour les contrôles release-level.
control plane
Noyau, routing, policy, readiness
eloractl
Statut, doctor et chemins du control plane. C'est l'entrée courte pour inspecter l'état local autoritatif.
elora-readiness
Construit la readiness matrix: control plane, providers, agents, playbooks, harnesses, mission runtime, evidence, verification, inventaires E2E/trials, context files et queue. matrix donne l'état complet; core-v1 agrège matrix, cockpit-direct-smoke et Mission V0 Acceptance pour donner un verdict opérateur sur le chemin cockpit/CLI quotidien; core-v1 --fast est la variante bornée utilisée par le cockpit pour afficher un timeout visible au lieu de bloquer longtemps; degraded résume ce qui reste utilisable quand Telegram, Hermes, Ollama, PostgreSQL ou un provider distant sont absents; cockpit-direct-smoke vérifie le chemin cockpit/CLI sans mutation.
elora-capabilities
Liste, inspecte et diagnostique les capacités locales ou directes: web, browser, vision, audio, image, forecasting, etc.
elora-policy
Expose les classes de policy et l'évaluation des overrides. Sert à rendre les bornes explicites avant action.
elora-router
Expose la matrice de routage et classe une demande vers une route/task class auditable.
elora-provider
Liste, teste, sélectionne et appelle les providers configurés, local-first et OpenAI-compatible quand applicable. runtimes expose les bindings provider/runtime et leurs capacités; select --capability code|reasoning|chat --task-class ... montre le provider retenu sans appeler de modèle; compare compare des candidats en dry-run par défaut. L'inférence locale exige --execute-local, et les providers connectés exigent aussi --allow-connected.
elora-audit / sxaudit
Lit les traces d'audit: liste, tail et stats. Sert à vérifier ce qui a été lancé, par qui, avec quel statut.
operator surfaces
Surfaces locales et conversationnelles
elora-chat
Entrée de dialogue locale utilisée par les surfaces conversationnelles. Une mission claire produit un plan de mission conversationnel; les tours courts de confirmation, ajustement, annulation, statut, continuation ou revue passent par elora-intent et son contrat elora.intent.v1. Après une confirmation valide, le Conversation-to-Execution Bridge tente elora-execute mission --apply --dispatch avec contexte par fichier, refuse les reroutages implicites d'agent, puis expose execution_bridge, execution_id et queue_id quand le chemin est prêt.
elora-console
Console interactive locale: sessions, messages, queue, résultats, bindings et recherche.
elora-terminal
Client terminal local en Python avec rendu configurable.
elora-cockpit
Commande d'administration du cockpit loopback: snapshot, check, serve, start, status, logs, stop et open. start lance un processus local détaché sans dépendance systemd.
elora-turn
Gère les tours conversationnels: start, status, events et cancel.
elora-session
Sessions, branches, messages, contexte, pièces jointes, bindings surface/key et recherche locale.
sxtelegramd
Daemon Telegram de continuité. Il reste une surface secondaire, pas le control plane.
mission lifecycle
Opérations, intentions, missions, résultats
elora-operate
Mission Control déterministe: brief, triage, next, plan-day et handoff d'une next action.
elora-brief
Raccourci vers le brief du daily operating core, utile pour résumer projets, open loops, décisions et prochaines actions.
elora-strategy
Strategic Operating Loop: weekly pack, weekly review, objective action, daily board, operator ritual, brief stratégique, triage texte, séquence proposal-only et review. ritual --mode start|check|close --json donne la cadence de session sans mutation; objective-action OBJECTIVE_ID --json prévisualise une next-action liée au cap; --apply crée seulement cette next-action operator-core, sans modèle, worker, mémoire, routing ou provider mutation.
elora-intuitions
Capture une intuition opérateur et la transforme en séquence exécutable locale.
elora-sequences
Alias orienté séquences autour d'elora-intuitions.
elora-attention
Attention guard: focus windows, not-now, demandes entrantes et triage sans modèle.
elora-operator-state
Ledger local de contexte opérateur: énergie, fatigue, contraintes, engagements, soutenabilité et context pack read-only pour le board stratégique.
elora-ops
Daily operating core: projets, open loops, décisions, next actions et objectifs stratégiques.
elora-projects, elora-open-loops, elora-decisions, elora-next, elora-objectives
Raccourcis spécialisés vers les sous-domaines d'elora-ops. elora-objectives alimente le cap semaine/jour sans devenir Memory V2.
elora-execute
Execution Handoff: plan, catalogue Golden Path Missions, golden-run avec inputs structurés et snapshot d'audit, golden-pilots/golden-pilot pour relier les missions standard aux preuves elora-trial/elora-e2e, mission-pilots/mission-pilot pour transformer ces chemins prouvés en pilotes opérateur prêts à lancer, certify-golden-paths pour distinguer chemins mappés et chemins certifiés par full E2E local, mission libre avec --context-json-file pour les gros evidence packs, cycle guidé, pending missions avec pending-show, clarify et pending-cancel, board, mission execution loop avec timeline/gate summary, operator-loop pour le contrat quotidien "quoi faire maintenant", daily-brief pour le brief compact affiché en premier dans le Workbench, daily-flow pour l'état cockpit-ready du jour avec completion, qualité, next-safe-action et readiness finale, supervised-flow pour la carte supervision mission read-only/action-selection-only, result-flow pour la décision résultat et réponse finale, start, dispatch, sync, review, safe-continue pour avancer jusqu'au prochain arrêt sûr sans dispatch/close implicite, redo, revise, attempts, compare, arbitrage qualité résultat, synthèse livrable, livraison finale avec Final Operator Answer, mission outcome, Mission Supervisor, auto-runner bas niveau, learn, close et feedback.
elora-mission
Cadre et clarification de mission: transforme une demande en frame opératoire avant routage ou exécution.
elora-playbook
Scaffolds déterministes par domaine: inputs, artefacts, quality gates et runs playbook.
elora-harness
Vérifie la readiness de scénarios de mission sans lancer worker, modèle, mémoire ou routing.
elora-trial
Classe les chemins agents entre readiness-only et full E2E-proven en agrégeant elora-harness et elora-e2e. Il expose aussi coverage_status pour distinguer preuve E2E, gap actionnable et readiness-only par policy, sans modèle ni mutation implicite.
elora-e2e
Harness E2E isolé: mission libre, dispatch, queue, worker local, result contract, review, learning preview, feedback preview et close readiness.
elora-acceptance
Mission V0 Acceptance: doctor, scénarios et check rapide du chemin quotidien naturel objectif -> plan -> go -> mission inspectable. Le check utilise une racine de données isolée, vérifie le plan conversationnel, le go explicite, la readiness mission, les questions de clarification, Golden Paths et Mission Pilots, sans Telegram, Hermes, Codex, provider distant, modèle, écriture mémoire ou mutation routing/provider. --include-e2e ajoute volontairement le chemin E2E lent.
elora-live-run
Preuve cockpit-mediated: démarre un cockpit loopback isolé, extrait le token local, vérifie refus auth/confirmation, traverse les APIs cockpit, lance sxcore run-once, puis sync, review, synthesis, delivery, feedback, outcome, learning et close. Le rapport expose aussi mission_operations: état safe/warning/blocked, compris, contexte, routing, gates, timeline, artefacts et prochaines actions. C'est une preuve du chemin opérateur cockpit, pas une autorité navigateur.
elora-result
Valide et inspecte les result contracts, artefacts, fichiers obligatoires et manifests.
elora-evidence
Construit, résume et inspecte les evidence packs L0/L1/L2/L3 pour session, playbook, exécution, queue ou fichier. Le pack expose aussi external_context_boundary: les contenus externes sont data-only et sans autorité d'instruction.
elora-verify
Claim Verification Gate: claims, plan, execute, cross-check, inspect et doctor sans mutation implicite.
elora-explore
Exploration distributionnelle et semantic collision: candidate sets, tail options, red-team, synthetic evals et validation.
elora-guarded-exec
Wrapper d'exécution bornée autour d'un programme réel, utilisé pour garder une trace contrôlée.
agents learning
Agents, excellence, learning proposal-only
elora-agent
Catalogue agents: list, show, resolve, reality, competence, excellence, scenarios, gold, eval, operational, run, status, result, review, feedback et learning. operational fusionne inventaire, contrats, fixtures, trials et Golden Paths en matrice read-only, avec safe_actions, next_safe_action et argv structuré pour les diagnostics sûrs côté cockpit.
elora-capability
Capability Factory proposal-only: template, propose, validate, promote-plan, show, list et doctor pour créer un pack de capacité puis un dossier de promotion reviewable. promote-plan génère des patches candidats agent, playbook, compétence, excellence, fixture et harness sous ELORA_DATA_DIR/capability-factory/, sans créer d'agent opérationnel ni muter la config active. Le cockpit expose la même autorité via /api/capability-factory et /api/capability-factory/promote-plan; l'application demande GENERATE CAPABILITY PROMOTION.
elora-agent-improve
Workbench d'amélioration opérateur: review, patch proposal, apply explicite et historique des patches.
elora-agent-traces
Import et analyse locale de corpus de traces agentiques. Produit des propositions, pas des mutations.
elora-learning
Capture, inbox, feedback, proposals, promotion explicite, pattern scores, trends, scorecards et revision-review.
sxqueue
File de travail durable: add, list, overview, show, result, set, move, retry, requeue, purge et recover-running.
sxapprove
Demandes d'approbation: submit, list, show, approve, deny.
memory context
Mémoire, contexte, retrieval, persona interne
elora-memory
Memory V2: paths, doctor, bootstrap SQL, migrations, archives, entries, search, links, contradictions et mirror selon les sous-commandes.
elora-ingest
Ingestion de documents et entries: archive brute d'abord, candidates seulement si demandé, dry-run possible.
elora-retrieve
Retrieval local: entries canoniques d'abord, archive/chunks comme evidence fallback.
elora-context
Construit le runtime context pack d'un tour conversationnel: session, route, retrieval plan, evidence et guards.
elora-context-files
Registre et pack de fichiers Markdown vivants attachables à une mission. Ils ne remplacent pas PostgreSQL et sont transmis aux workers via wrapped_content, pas comme instructions brutes.
elora-context-trust
Classe et enveloppe les contenus externes ou non fiables: web, PDF, Markdown collé, email, transcript, OCR ou snapshot navigateur. Le contenu devient data-only evidence, sans autorité pour muter mémoire, routing, providers, policy ou exécution.
sxmemory
Mémoire historique simple: add, learn-failure, list, show et stats. Utile comme couche de transition/compatibilité.
sxpersona
Gestion des personas internes: list, active, show, validate, activate et compile.
sxbrief / sxchief
Briefs et vues chief historiques: daily, status, decisions et prompt. Ils restent internes à l'orchestration.
local capabilities
Recherche, web, multimodal, modèles locaux
elora-models
Cookbook local des modèles: scan runtime/hardware, recommandations par tâche et doctor. Il ne télécharge rien, ne benchmarke pas et ne modifie ni routing, ni provider.
elora-fetch
Fetch web direct via provider local, avec sortie bornée et sauvegarde optionnelle.
elora-search
Recherche locale/directe, par défaut dans le corpus repo via rg.
elora-scrapegraph
Extraction sémantique locale optionnelle: baseline HTML déterministe pour tests, backend ScrapeGraphAI/Ollama quand installé, source snapshot et artefacts qualité. Le résultat est une hypothèse, pas une preuve canonique.
elora-browser
Inspection rendue par navigateur local headless avec artefacts optionnels.
elora-image
Génération d'images via providers locaux configurés, par exemple SD WebUI ou ComfyUI.
elora-vision
Description d'image locale/directe, avec provider simple quand Pillow est disponible.
elora-ocr
OCR local/direct quand le provider correspondant est disponible.
elora-stt
Speech-to-text local/direct, orienté Whisper/faster-whisper/whisper.cpp selon configuration.
elora-tts
Text-to-speech local/direct, orienté Piper quand disponible.
elora-ollama
Opérations autour du runtime local Ollama: status, doctor, profiles, launch-plan, logs, providers, start, stop et warm. Les profils déclarent aussi local_llama_cpp, local_dgx_gb10_llama_server et remote_ssh_llama_server. launch-plan --all --json donne les commandes opérateur pour démarrer/prober/smoker ces runtimes sans auto-lancement distant ni dépendance systemd.
elora-timeseries
Forecasting séries temporelles local: TimesFM optionnel ou baseline déterministe pour tests.
deterministic workers
Workers locaux bornés
Ces workers partagent le contrat run --repo PATH --prompt-file FILE puis report --queue-id ID --run-id ID --json. Le cockpit peut les lister via /api/workers, lancer les chemins queue-compatibles via /api/worker/run, relire le lifecycle via /api/worker/lifecycle, attacher un run direct au lifecycle mission via /api/worker/attach, et enregistrer un feedback proposal-only via /api/worker/feedback. Chaque run direct conserve preflight gate, result contract, quality gate, learning hint, chemins d'artefacts et feedback local. Le result.json est normalisé: il garde les champs natifs du worker, ajoute native_result, expose un deliverable validable par elora-result, et référence result.md, quality.json, artifacts/native_result.json, artifacts/native_quality.json et le manifest. elora-execute attach-worker crée ensuite une exécution direct_worker déterministe, compatible avec synthèse, livraison, feedback, outcome et fermeture. Ce launcher ne remplace pas elora-execute: il sert aux lancements opérateur directs de workers locaux connus.
elora-site
Worker déterministe d'analyse de site ou page: contenu observé, evidence table, recommandations, sans contact externe.
elora-docs
Worker déterministe d'analyse documentaire et de mise à jour docs bornée: Markdown, texte, PDF extractible, claims/risques candidats, plan documentaire, validation notes et journal draft.
elora-code
Worker code local: fallback sans Codex/Claude/Hermes, génération optionnelle via modèle local OpenAI-compatible, backend OpenCode en analyse read_only, édition bounded ou trusted_free pour créer/modifier une application locale, lancer des commandes et conserver stdout, stderr, status Git, diff, fichiers changés, result JSON et quality JSON. runtime status --probe --json vérifie la configuration et /v1/models sans inférence; runtime smoke --execute-local --json lance un appel modèle minimal, explicitement local, sans worker dispatch ni mutation. backends select --json expose le backend résolu: native pour certains artefacts déterministes, local_model pour un modèle local code/raisonnement, opencode pour un client local capable de travailler sur le repo. GLM-5.2 est le candidat recommandé quand il est servi localement via ELORA_LOCAL_CODE_MODEL, mais le worker reste indépendant du modèle. elora-code patch inspect/decide ajoute le gate d'acceptation opérateur du diff sans commit automatique. Tester OpenCode par ce wrapper valide le câblage Elora; un opencode run brut reste hors policy, hors artefacts Elora et peut utiliser le provider par défaut d'OpenCode.
elora-forecast
Wrapper queue-compatible autour du forecasting local. Les prévisions restent des hypothèses.
elora-prospect
Worker local de prospection StackX: inventaire cible, scoring, contact candidates visibles, brouillon outreach avec disclosure IA et rapport de revue. Il ne contacte personne.
elora-support
Worker local de triage support: lit un ticket et des preuves fournies, produit classification, evidence gaps, next actions, rapport et brouillon client avec disclosure IA. Il ne contacte personne et ne mute aucun ticket. Le cockpit l'expose via la console Support dédiée et via le Worker Registry commun, mais l'autorité reste ce binaire.
historical wrappers
Wrappers et services historiques
sxcodex
Worker Codex: run, resume, review et report. Codex est un spécialiste, pas Elora.
sxhermes
Worker Hermes: run, resume, review, report et doctor. Hermes reste un overlay optionnel.
sxcore
Runner core durable: run-once, run et status.
sxctl
Contrôle historique du core: init, status, pause, resume, stop.
sxmaint
Maintenance et notifications: rétention, nettoyage contrôlé et hooks de notification.