Premier pilote CLI Aune

État du 24 septembre 2026. Ce document décrit le code disponible ; le concept d’architecture demeure la cible plus large.

Périmètre livré#

La CLI réutilise réellement @matrice-technologies/served-tool, fourni par une copie locale de la révision examinée. Sa construction produit cli/aune.mjs, autonome à l’exécution, ainsi qu’un registre de versions du tool et du skill. La plateforme sert les mêmes fichiers.

Le pilote traite uniquement des exercices fictifs personnels, au rôle de structuration. Le contributeur récupère trois segments, leurs instructions figées et une grille de méthode. Il extrait des assertions sourcées, dépose une révision et la soumet. Le statut final est pending_human_review. Aucun modèle n’est appelé par le serveur et aucune analyse politique réelle n’est fournie par ce pilote.

Les commandes métier renvoient du JSON. Les commandes de connexion et de cycle de vie du socle conservent leur présentation humaine ; l’option --json ne rend pas toutes ces commandes uniformes.

Préparer la plateforme#

1. Utiliser Node.js 24 ou supérieur, installer les dépendances et lancer npm run cli:build.
2. Configurer Supabase pour la connexion humaine selon le README. Le serveur vérifie la session auprès de Supabase ; aucun mode de connexion fictive n’est activable dans l’application publique.
3. Prévoir AUNE_DATA_DIR pour les données du pilote. En développement seulement, son défaut est .local/aune. En production, la variable est obligatoire et doit désigner un volume persistant. Configurer aussi NEXT_PUBLIC_SITE_URL avec l’origine HTTPS réelle.
4. Lancer l’application. /cli expose le parcours, les téléchargements et les versions aux contributeurs connectés ; depuis le 25 septembre 2026, l’interface agents n’apparaît plus sur le site public.

SQLite conserve les empreintes de clés, demandes de connexion, tâches, tentatives, versions, soumissions et reçus d’opérations. Les identités et fonctions organisationnelles existantes restent dans Supabase. Ce choix rend le pilote utilisable sur une instance unique et testable sans une base distante. Une exploitation multi-instance demandera un adaptateur transactionnel partagé ; ne pas multiplier les réplicas sur ce fichier.

Sauvegarder le répertoire de données avec une procédure cohérente pour SQLite et son journal WAL. Les données et clés de travail ne font jamais partie du dépôt Git.

Connecter un terminal#

Le script est téléchargeable à /api/cli/aune.mjs. L’installateur facultatif à /api/cli/install vérifie son empreinte puis le place dans ~/.local/bin/aune. Il ne connecte pas le compte et n’installe aucun skill global de sa propre initiative.

node cli/aune.mjs login http://localhost:3000

Le terminal affiche une adresse et un code. L’utilisateur se connecte au site, saisit le code à /login/device, vérifie l’appareil et les droits puis autorise. Le terminal seul reçoit la clé. Elle est écrite dans ~/.config/aune/config.json avec des permissions restrictives. Ne jamais afficher ce fichier dans une conversation.

La durée est de sept jours avec écriture ou de trente jours en lecture seule. Les clés sont révocables à /cli/keys. La révocation est contrôlée sur chaque requête. Une clé ne peut pas approuver une connexion, approuver une analyse ou publier une édition.

Sans Supabase ou sans le stockage exigé, les opérations authentifiées restent indisponibles. La distribution du script, du skill et l’écran explicatif fonctionnent néanmoins. Aucune autre identité n’est utilisée pour contourner cette absence de configuration.

Réaliser un exercice#

Exemples avec l’outil installé sous le nom aune :

aune tasks demo
aune tasks ls
aune pull <identifiant-retourné> ./exercice-aune
cd exercice-aune
aune doctor
aune run start --runtime session-externe

Lire skill/SKILL.md, task.json et method/grille.md. Préparer une assertion par fichier JSON selon skill/reference/model.md, puis utiliser :

aune put assertions/assertion-001 @outputs/assertion-001.json
aune diff
aune validate
aune push -m "Assertions extraites des segments fictifs"
aune run finish @outputs/bilan.json
aune submit -m "Demande de revue des assertions"

Le bilan est un objet avec deux textes, summary et limitations. Chaque segment doit être cité ou exclu explicitement avec un motif avant soumission. Une même citation ne prouve ni la qualité de la reformulation ni l’exactitude d’un classement politique ; les contrôles restent structurels et documentaires.

Les assertions déposées, citations et statut sont consultables à /cli/tasks. La décision de revue et la publication ne sont pas implémentées dans cette première tranche. Les résultats ne deviennent pas publics par un dépôt.

Reprise et conflits#

La CLI prépare un reçu d’opération local avant une mutation. Si la réponse se perd, aune retry rejoue le même identifiant et reçoit le résultat enregistré, sans créer une seconde révision. Après un refus définitif, le brouillon local est conservé.

Le premier pilote applique une concurrence optimiste à la tâche entière. Si la base a changé, il refuse le dépôt. Pour réconcilier, récupérer la tâche dans un autre dossier vide puis comparer et reporter explicitement le travail pertinent. pull ne fusionne pas automatiquement et n’écrase jamais un dossier non vide.

Une tentative terminée ne peut plus déposer. Une nouvelle tentative est nécessaire pour une révision supplémentaire. Une soumission nomme la révision exacte finalisée ; une révision ultérieure ne reprend pas implicitement ce statut.

Versions et portée des garanties#

Les méthodes et instructions sont copiées dans le paquet de tâche et conservées en base à sa création. Les fichiers du paquet portent leurs empreintes. doctor vérifie l’intégrité locale et la compatibilité de la CLI ; le serveur compare les versions et valide le contenu des dépôts contre ses propres passages.

Le pilote accepte uniquement les compteurs de CLI et de skill figés pour la tâche. Il ne fournit pas encore un catalogue de téléchargements des anciennes CLI. Conserver le binaire associé à une tâche ; une nouvelle version peut nécessiter de recommencer un exercice. La distribution d’archives et la révocation de versions figurent dans la cible d’architecture, pas dans cette première livraison.

L’auteur, l’identifiant de clé, les heures de réception, les révisions et les reçus sont établis côté serveur. Le nom du modèle, l’environnement de session et le bilan sont déclaratifs. Le pilote ne prouve pas l’indépendance d’agents et ne mesure pas leurs coûts externes. Les clés autorisent les tâches personnelles de leur propriétaire ; les habilitations fines et vues masquées des corpus réels restent à construire.

Vérifications disponibles#

• npm test : six scénarios couvrant plusieurs assertions, dont connexion par code, récupération unique de clé, isolement des propriétaires, droits en lecture seule, citations, couverture, versions, persistance, reçus et parcours de la CLI compilée.
• npm run test:served-tool : tests amont du socle conservé sans modification.
• npm run lint, npm run typecheck, npm run build : qualité et compilation du projet.
• npm run test:smoke : parcours HTTP de la version non configurée, téléchargements, distribution de la CLI et fermeture des espaces privés.

Les tests de session humaine du cœur API utilisent des identités fictives injectées par le banc d’essai. Ils ne remplacent pas la vérification de la connexion réelle Supabase sur l’instance qui sera configurée.