Septembre 2026
Point daté du . Les résultats ci-dessous distinguent le cœur permanent, les expériences isolées et les travaux encore en cours. Elora reste le contrôle opératoire ; un modèle plus capable ne reçoit pas davantage d'autorité.
Continuer après le retour du client
Un mandat persistant borne désormais la mission : objectif, session, worker, périmètre et ressources. Le superviseur local reprend les transitions autorisées avec le consommateur de queue existant. Une mission réelle Astra/ultra a préparé une petite proposition sur les métadonnées d'Elora, passé la syntaxe Bash et six contrôles indépendants, puis livré une seule réponse vérifiée après le retour du client initiateur. Le patch n'a pas été appliqué au cœur actif.
Le superviseur permanent est suivi par une unité utilisateur systemd ; les commandes du cœur restent distinctes de cet adaptateur. Livraison technique, satisfaction de Christophe, application du patch et déploiement ne sont pas synonymes. Un reboot physique et toutes les situations de panne ne sont pas qualifiés par cette seule preuve.
Ce que les essais locaux prouvent réellement
OpenCode 1.18.29 est installé durablement. Les propositions locales exigent un contrat explicite, une copie isolée, des fichiers de référence protégés et des tests exécutés par Elora. L'autorisation réseau est séparée : la frontière native disponible couvre l'hôte loopback et ses ports, pas un port unique. La validation indépendante garde le réseau fermé.
GLM-4.7-Flash a réussi un petit parcours Bash isolé, mais une reproduction sous le superviseur permanent a stagné à 9/10 après corrections. Elora a refusé le résultat. Ce refus fait partie de la preuve, au même titre qu'un succès.
Un serveur expérimental GLM-5.3-Flash sur un seul Spark a ensuite produit un script Bash accepté par la syntaxe, ShellCheck et dix cas indépendants. L'exercice suivant, MiniPlan, demande trois modules Python, une CLI JSON et un README : la première proposition complète passe 85/86 contrôles figés ; quatre des huit contrôles CLI complémentaires échouent. Une correction écrite par GLM atteint 86/86 et 8/8, plus la compilation. Les limites de contexte annoncées au client et la compaction ont permis la continuation.
Ce résultat multi-fichiers a nécessité plusieurs essais et un banc explicitement supervisé. Il ne qualifie ni toutes les tâches de code, ni une correction rapide, ni une boucle GLM autonome en production. MiniPlan n'est pas le scheduler d'Elora. Le modèle permanent n'a pas été remplacé, les sources initiales restent intactes et les serveurs d'expérience sont arrêtés.
Consolider le banc de validation
Une revue distincte du 7 septembre apporte des correctifs dans le dépôt de développement : limites de contexte/sortie déclarées et scellées au GO, supervision des descendants avant le calcul des empreintes, et distinction entre défaut de qualité révisable et refus d'autorité qui ne doit pas provoquer de tentatives inutiles. Des tests déterministes vérifient ces contrats. Les libellés séparent parcours configuré et preuve historique ; la navigation retrouve août et ajoute septembre.
Une vérification native isolée d'OpenCode 1.18.29, sans réseau ni appel modèle, confirme que la configuration Elora de 32 768 tokens de contexte, 8 192 de sortie et compaction automatique reste effective face à une configuration projet contradictoire en lecture seule. Elle ne teste pas une compaction réelle. Le profil permanent GLM-4.7 n'est pas modifié : ses limites encore inconnues bloquent désormais ce mode de proposition. Les régressions ciblées de mission, correction et livraison passent avec des workers inertes ; ni GLM-5.3-Flash en production, ni un nouveau déploiement, ni la publication du site ne sont qualifiés par ce lot.
Les preuves et limites des providers/workers, la séparation des responsabilités et la FAQ donnent le détail. Les entrées précédentes restent des archives datées, pas une promesse sur toute installation.