Ce qui n'existe pas

Lemniscate est un fork rebrandé. Le projet dont il est issu s’accompagnait d’un service en ligne — un plan de contrôle et un registre de contenus partagés — et une partie du code du poste sait encore lui parler.

Ce service n’est pas opéré. Les commandes, les réglages et les écrans qui en dépendent existent toujours dans le produit : ils s’affichent, ils s’autocomplètent, ils apparaissent dans l’aide. Ils n’aboutissent pas.

Cette page les nomme. Elle existe pour une raison précise : ces chemins échouent tard, avec des messages qui ressemblent à des erreurs de configuration. Sans cette liste, on cherche l’erreur chez soi.

Comment on le sait

Le constat ne repose pas sur une tentative d’appel, mais sur des preuves internes au dépôt :

• un test du chargeur de contenus porte en commentaire que le domaine d’API « n’existe pas encore » ;
• les tests dits « Real Hub » sont désactivés en intégration continue ;
• npm view @lemniscate/cli répond E404 : rien n’est publié sous ce nom ;
• six workflows d’intégration continue qui visaient ce service ont été supprimés parce qu’ils échouaient tous les jours ;
• aucune moitié serveur de ce service n’existe dans le dépôt.

Côté CLI

L’authentification au compte. lemni login, lemni logout, et leurs équivalents en session /login, /logout, /whoami. Le flux d’authentification par device code s’adresse à un fournisseur d’identité tiers avec un identifiant client hérité, qui appartient au locataire de l’éditeur d’origine. Même si ce flux aboutissait, le jeton obtenu ne sert qu’à parler à l’API absente. Le fichier ~/.lemniscate/auth.json qu’il produirait n’a pas d’autre usage.

Ce qui désigne un contenu publié. Les drapeaux --org <slug>, --mcp <slug> et --model <slug> résolvent un identifiant propriétaire/paquet contre le registre distant. Sans registre, aucun slug ne se résout.

Ce qui suppose une exécution hébergée. lemni remote et ses options, lemni serve --id <storageId> qui pousse un instantané de session vers un stockage géré par l’éditeur, et l’outil de téléversement d’artefacts qui va avec.

La mise à jour. /update et la vérification de version au démarrage interrogent le canal de publication. Il n’y en a pas : Lemniscate n’est pas publié sur npm, et ne le sera pas. Le canal réel est l’artefact construit avec le profil on-premise.

Un piège moins visible. La commande racine lemni a besoin d’un fichier ~/.lemniscate/config.yaml. En son absence, et sans authentification, la résolution de configuration retombe sur une configuration par défaut distante, qu’elle demande à l’API absente — et le démarrage échoue. Ce n’est pas un bogue de la configuration locale : c’est le repli qui part chercher ailleurs. Avoir un fichier de configuration local est ce qui rend le CLI autonome.

Côté extension VS Code

Les agents en arrière-plan. Le mode background et les trois actions qui l’accompagnent — créer un agent, lister l’historique des agents, rouvrir une session d’agent en local — passent par le client du plan de contrôle. Le chemin exige de surcroît un dépôt hébergé sur GitHub et une connexion GitHub établie à travers ce même plan de contrôle.

La connexion au compte. Le fournisseur d’authentification et le gestionnaire de liens profonds lemniscate:// sont enregistrés sans condition au démarrage de l’extension, ce qui rend l’entrée visible. Sa cible est le service non opéré.

La configuration partagée. La récupération périodique d’une configuration d’équipe depuis un serveur, et le rechargement de l’extension à chaque changement, dépendent du même service.

Côté configuration

Le bloc uses:. Le schéma de config.yaml accepte partout la forme uses: propriétaire/paquet, avec with: et override:, pour réutiliser un bloc publié ailleurs. La résolution d’un tel identifiant appelle le registre du plan de contrôle.

La même clé a une forme locale, qui fonctionne : un identifiant qui commence par ., / ou ~ — ou qui porte explicitement le protocole file:// — désigne un fichier du poste et ne sort jamais de la machine. Tout le reste est lu comme un slug de registre. C’est la distinction à garder en tête, parce que la clé s’écrit pareil dans les deux cas :

models:
  # Chemin local : résolu sur le poste.
  - uses: ./blocs/relais-interne.yaml
  # Slug : résolu par le registre distant, donc jamais résolu.
  - uses: proprietaire/paquet

L’autocomplétion des modèles. L’éditeur propose une liste figée de slugs de modèles courants quand on écrit uses: sous models:. Cette liste est injectée dans le schéma JSON, donc elle apparaît dans l’IDE — mais chaque entrée devrait être résolue par le registre distant. Une suggestion acceptée ne produit pas une configuration valide.

provider: free-trial. L’essai gratuit qui passait par le proxy du projet d’origine n’est plus supporté. Les modèles qui le déclarent sont filtrés au chargement, avec un message qui le dit.

Ce qui n’existe pas encore : le confinement de l’exécution agentique

Cette section n’est pas de la même nature que les précédentes. Il ne s’agit pas d’une surface héritée qui parle à un service disparu, mais d’une garantie que le produit vise et ne tient pas encore. Elle est ici parce que la confondre avec une garantie acquise coûterait plus cher que tout le reste de cette page.

L’agent s’exécute sur le poste du développeur, sous son compte, avec son environnement. Il n’y a ni conteneur éphémère par session, ni copie de travail : l’agent opère sur l’arbre réel. Les profils de durcissement livrés avec le produit — seccomp, AppArmor, capacités retirées — s’appliquent au serveur sur lequel la passerelle est déployée, pas au poste.

Le produit le dit : au démarrage, il écrit sur sa sortie d’erreur où l’exécution a lieu et ce que cela implique. Cette annonce n’apparaît que lorsque la garantie n’est pas tenue — ce qui est le cas de toute construction actuelle. Le lieu se règle par LEMNISCATE_AGENT_EXECUTION, dont la seule valeur acceptée aujourd’hui est workstation ; sans configuration, le produit demande le serveur, ne le trouve pas, et l’annonce.

Ce qui, en revanche, existe et ne dépend pas du lieu : la politique de permissions, l’analyse des commandes avant exécution, l’interprète choisi par le produit — sans le profil du shell de l’utilisateur —, les bornes de session et de commande, et le journal des appels d’outils.

Les environnements d’exécution distants ne sont plus publiés. Les images qui servaient à lemni remote étaient construites chez un tiers hors d’Europe, sans verrou d’isolation ; leur publication a été arrêtée. La commande subsiste dans le produit et n’aboutit pas — pour la même raison que les autres surfaces de cette page.

Ce qui n’est pas concerné

Le trio serveur — llm-gateway, gateway-db et gateway-admin — n’a rien à voir avec ce service hérité. Il est livré au client, tourne chez lui, et ne dépend d’aucun plan de contrôle. Sa configuration vit dans sa base, pas dans un registre distant.

C’est la confusion la plus coûteuse à faire en lisant cette page : « une partie du produit parle à un service qui n’existe pas » ne veut pas dire « le produit dépend d’un service qui n’existe pas ». Le chemin qui va de l’éditeur de code au modèle de langage, en passant par la passerelle, est autonome de bout en bout — voir Le rôle de la passerelle et Architecture.

Comment reconnaître un nouveau cas

Trois signaux, dans le code comme à l’usage :

1. la surface parle d’organisation, de compte, d’assistant partagé, de registre ou d’agent distant ;
2. son chemin d’exécution traverse le client du plan de contrôle (core/control-plane) ;
3. elle demande un identifiant de la forme propriétaire/paquet.

Une surface qui coche ces cases n’aboutira pas, quelle que soit la configuration locale.