- start/restart : preflight (BIN, MODEL, .gguf) et fin du faux « [ok] activating »
sur un service qui redemarre en boucle (SubState auto-restart).
- MODEL en chemin absolu accepte hors des dossiers declares (lecture seule) ;
l'allowlist reste sur la suppression de fichiers.
- ajean edit : squelette commente des cles au lieu d'un fichier quasi vide.
- install : les prochaines etapes n'oublient plus « ajean llamacpp install ».
- Presets : un nouveau preset ne recopie plus la config active (issue #17),
seulement BIN/HOST/PORT.
- Presets : plus de guillemet interne mange a la relecture (Go et interface),
et EXTRA_ARGS decoupe en respectant les guillemets.
Trois defauts signales a l'usage.
1. Le binaire 0.8.0 se DECLARAIT 0.7.13 a Windows : j'avais bump la constante Go
sans toucher a cmd/ajean/versioninfo.json ni regenerer les .syso. D'ou le
« version en cours 0.7.13 / ce fichier 0.8.0 » a chaque relance du fichier
telecharge. Ressource remise a 0.8.0, .syso regeneres, et un test garde
desormais les deux en phase.
2. Des fenetres de console apparaissaient : la relance apres installation et
l'ouverture du navigateur creaient un enfant sans masquer sa fenetre, ce qui
se voit maintenant que le binaire est en sous-systeme console. Les deux
passent par hideCmd. Les raccourcis DEJA poses recoivent en plus le demarrage
minimise, qui ne s'appliquait qu'aux nouveaux.
3. Deux builds de meme version n'etaient jamais remplaces : relancer un
telechargement plus recent d'une preversion republiee demarrait simplement
l'ancienne copie. On compare desormais les fichiers (taille puis SHA-256) et
non les seuls numeros.
Au passage, l'icone est epinglee sur le raccourci : Windows garde parfois en
cache celle d'un binaire remplace et affiche un carre blanc.
ShowWindow etait cherchee dans kernel32 alors qu'elle vit dans user32.
LazyProc.Call PANIQUE quand la procedure est introuvable, et setupConsole
s'execute avant tout le reste : le programme mourait sur le champ, sans rien
installer et sans rien afficher. Seul le chemin du double-clic etait touche
(console creee pour nous), d'ou une CI verte et des tests CLI qui passaient.
Tous les appels Win32 de ce fichier passent desormais par un helper qui verifie
la presence de la procedure au lieu de paniquer : aucun reglage de confort ne
justifie d'empecher le programme de demarrer.
Verifie de bout en bout cette fois : lancement facon double-clic -> arborescence
creee, bin/ajean.exe installe, aucune panique, processus vivant ; et les chemins
CLI (ordre d'affichage, redirection, tube, aide sans argument) inchanges.
Dans un terminal, cmd rendait la main avant qu'ajean n'ait rien ecrit : l'invite
se reaffichait puis la sortie arrivait par-dessus. Windows n'attend jamais la fin
d'un programme en sous-systeme graphique. La meme cause empechait les
redirections et les tubes, et rendait 'ajean chat' inutilisable (le shell et
ajean se disputaient l'entree).
Le binaire passe donc en sous-systeme console. La fenetre noire au double-clic,
que le sous-systeme graphique evitait, est traitee autrement : quand aucun autre
processus ne partage notre console, c'est que Windows l'a creee pour nous, donc
que personne ne nous a lances depuis un terminal. On la masque et on la libere.
Les raccourcis demandent en plus un demarrage minimise.
La relance interne (apres mise a jour) passe desormais 'app' explicitement : la
detection ne repond qu'a la question du double-clic, et un processus sans
console du tout ne doit pas avoir a y repondre.
Verifie : ordre d'affichage correct en session cmd, redirection et tube
fonctionnels, 'ajean' sans argument affiche l'aide, et aucune fenetre console
visible au lancement facon double-clic.
'ajean where > fichier.txt' n'ecrivait rien dans le fichier et 'ajean help |
findstr x' ne transmettait rien : tout partait sur la console.
Cause : le binaire etant en sous-systeme GUI, setupConsole reouvrait stdout,
stderr et stdin sur CONOUT$/CONIN$ pour avoir ou ecrire. Il ecrasait ce faisant
la redirection que le shell avait posee. Le test naif ne suffit pas :
AttachConsole REMPLACE lui-meme les handles standard par ceux de la console,
donc les interroger apres le rattachement ne montre jamais qu'une console. On
releve donc leur type AVANT d'attacher, et on ne reouvre que ceux qui sont
reellement inutilisables.
Verifie sur un binaire compile comme celui de la release (sous-systeme GUI) :
redirection vers un fichier, tube vers findstr, et affichage console inchange.
Le double-clic demandait « Installer AJEAN ou juste le lancer ? ». La question
n'avait qu'une reponse utile : rester a l'emplacement du fichier telecharge ne
donne pas une installation utilisable (aucun raccourci, rien dans le PATH, et
une application qui disparait le jour ou l'on vide ses telechargements). Faire
porter a l'utilisateur un choix qui n'existe pas ne l'aide pas.
L'installation se fait donc directement, et le message qui suit dit ce qui a ete
fait : ou le programme s'est installe, et que le fichier telecharge peut etre
supprime. Le repli en cas d'echec (droits sur %ProgramData%) est inchange.
Les deux autres boites de dialogue sont conservees : elles portent de vraies
decisions (fichier plus ancien que la version installee, fermer une application
en cours pour appliquer une mise a jour).
Le moteur tourne dans un process detache, qui survit volontairement a la
fermeture de l'interface pour garder le modele charge entre deux ouvertures.
Mais apres un « Quitter », plus rien ne le pilote et il conserve des dizaines de
Go de RAM sans aucune fenetre pour l'expliquer. La fonction de sortie du systray
appelle desormais svcStop, qui tue l'arbre (taskkill /T) donc llama-server avec.
Windows uniquement : c'est la seule plateforme ou l'app est proprietaire du
moteur. Sous Linux et macOS il appartient a systemd ou launchd, et fermer une
interface n'a pas a arreter un service systeme.
Le redemarrage apres mise a jour ne passe PAS par ce chemin (il a son propre
os.Exit), donc une MAJ ne dechargera pas le modele.
Elle n'est utilisee que par le tray macOS, que staticcheck ne compile pas hors
CGO. Sans cette directive, la CI (qui lance staticcheck sur ubuntu) echouerait
sur une fonction pourtant bien utilisee.
Deux defauts trouves a l'usage :
1. Impossible de saisir la cle de pilotage dans l'UI : le chargement lance une
dizaine d'appels /api/* en parallele, chaque 401 rouvrait la modale, et
celle-ci vide son champ a l'ouverture. Les caracteres disparaissaient au fur
et a mesure de la frappe. Une seule demande de cle est desormais partagee par
tous les appels concurrents. Au passage, une modale ouverte n'est plus
ecrasee en silence (sa promesse restait pendante pour toujours).
2. migrate_07 n'importait pas .authorized_users : les identites appairees pour
le chat chiffre. Symptome trompeur — le tunnel s'etablit, la machine
s'affiche en ligne, mais le portail refuse toute conversation. Importe et
couvert par un test.
brandTemplatePNG n'etait pas du code mort : sys_tray_darwin.go l'utilise pour
l'icone de barre de menus. Ce fichier ne compile qu'avec CGO, donc ni la
compilation croisee depuis Windows ni staticcheck sans CGO ne le voyaient — la
fonction passait pour inutilisee. Restauree.
sys_service_darwin.go affichait encore le chemin de config.env, disparu avec le
passage en base.
Le piege est documente dans doc.go : seul le job macos de la CI attrape ce genre
de regression.
- notes reecrites sans tiret cadratin (convention du projet), avec la marche a
suivre d'installation et la section de ce qui n'a pas ete teste
- migrate_07 archive aussi SKILLS/ (dossier mort depuis la fusion dans memory)
- commentaire d'en-tete de release.yml remis a jour
ajean-linux, ajean-linux-arm, ajean-macos, ajean-macos-arm,
ajean-windows.exe, ajean-windows-arm.exe.
Le schema ne correspond plus a ajean-<GOOS>-<GOARCH> que cherchent les 0.7 :
leur mise a jour automatique ne trouve aucun asset et echoue sans rien
remplacer. C'est voulu — sinon elle installait le binaire 0.8 sans migrer, le
service de lien repartait en boucle d'echec sur « link serve » disparu et le
moteur perdait sa configuration.
assetNameFor est isolee pour etre testee sur les six plateformes, plus un test
qui verifie explicitement l'absence de collision avec le schema 0.7.
Un seul fichier, migrate_07.go, sans dependance entrante : le supprimer et
retirer les deux appels suffira le jour venu. Declenchee UNIQUEMENT par install
(root, delibere) et non au demarrage, contrairement a ce qui existait en 0.7 et
qui pouvait laisser une machine distante sans service.
Deplace configs/->presets/, MEMORY/->memory/, les .gguf->models/, reprend l'etat
en base, range les anciens fichiers dans avant-0.8/ et desactive les unites jean*
(sans quoi un second llama-server demarrait au boot suivant).
Trois tests : le cas nominal, l'installation neuve, et la machine deja migree a
la main. Ils ont trouve deux bugs reels de casse de fichiers (MEMORY/memory se
confondent sur Windows et macOS).
- uiUserSvcCtl lancait encore « ajean link serve », sous-commande supprimee :
l'acces distant etait casse sur macOS et Windows (hors systemd)
- tools/migrate-0.7 : reprise d'une installation 0.7.x, hors du binaire pour ne
pas reintroduire de compat dans le produit ; procedure complete au README
- CI : staticcheck ajoute (le projet est a zero avertissement, il doit le rester)
- .gitignore purge de ses entrees mortes (jean, config.env, .api_key...)
- sys_install_unix.go porte le parcours commun (arborescence, lien du binaire,
/etc/default, chown) ; Linux et macOS ne gardent que leur declaration de
services derriere installServices/uninstallServices (395 -> 339 lignes, et
surtout une seule copie a corriger)
- l'installateur macOS pose desormais les DEUX services (il n'en posait qu'un)
- API bbolt depreciee remplacee, message d'erreur duplique factorise
- staticcheck.conf : ST1005 ecartee, avec la raison (messages francais montres
a l'utilisateur). Le projet est a zero avertissement.
- sysprompt, utilisateurs appairés, codes d'appairage et etat du job de build
passent en base ; ne restent des fichiers que la cle E2E, les certificats et
les journaux (le log de build reste un fichier : des milliers de lignes)
- doc.go remis a jour (run.go, store.go, les deux services, tools/assemble-ui)
- README et notes de release ne pretendent plus que la racine ne contient que
six dossiers : c'etait faux
Le champ 'config' de /api/paths est devenu 'database' : la ligne Configuration
s'affichait vide. Le panneau montre desormais la base, les modeles, les presets,
la memoire, le workspace et les backends.
- ajean.service -> ajean-engine, ajean-link.service -> ajean-ui
- 'ajean web' est desormais l'unique serveur d'interface : il ouvre aussi le
tunnel quand un jeton est enregistre (une seule conversation, plus de conflit
sur :8090 ni de fils divergents)
- 'ajean link' ne gere plus que le compte ; 'ajean ui' pilote le service
- l'installateur Linux pose les deux unites et les deux regles sudoers
- 'app' sort de l'aide
bbolt pose un verrou exclusif sur son fichier : le service de lien, qui tourne
en permanence, empechait toute commande CLI de s'executer a cote. La base est
desormais ouverte pour la duree d'une operation puis refermee, et les buckets
ne sont crees qu'a l'ecriture (une lecture ne coute plus un fsync : 3,8 ms ->
0,55 ms). Test de concurrence a l'appui.
- suppression des fonctions et types inutilises (staticcheck U1000)
- sources UI, workflows, README passes en ajean
- release.yml ne publie plus que les binaires ajean-*
- notes de release redigees
- suppression des alias de commandes herites (skills, machine, tools, mem, upgrade...)
- aide reecrite et regroupee
- helper de test testHome + fermeture de la base (verrou bbolt sous Windows)
- tests des dossiers de modeles alignes sur models/
- provisionDataDir unique pour les trois plateformes (six dossiers, config par defaut)
- plus de modele config.env duplique dans chaque installateur
- plus d'alias jean pose a l'installation
- suppression des migrations d'agencement, d'unites et de dossier de donnees
- store bbolt unique (ajean.db) : config, prefs, conversation, cles, drapeaux
- arborescence backends/ bin/ presets/ memory/ models/ workspace/
- plus aucune variable, unite ou asset nomme jean
- Preset actif : liseré gauche droit, rogné par l'arrondi de la carte, un peu plus large
- Puce de l'actif dessinée en CSS (même taille et même assiette sur Windows et macOS)
- Survol et sélection moins appuyés dans la liste
- Bascule : retour visuel immédiat (barre qui glisse depuis la gauche, atténuée puis
pleine) ; animations rejouées seulement quand la sélection change vraiment
- /api/switch répond sans attendre le redémarrage du service : bascule instantanée
- Bouton envoyer et touche Entrée désactivés tant que le modèle n'est pas chargé
- ecartement du binaire sous un nom unique : un reste verrouille par un ancien
processus ne fait plus echouer le remplacement (message "droits insuffisants,
relance en administrateur" qui etait faux, aucun privilege ne remplace une
image en cours d'execution)
- section Cartes graphiques masquee pour de vrai avec une seule carte :
l'attribut hidden etait sans effet, .pe-group{display:flex} l'emportait
Le remplacement du binaire renommait l'ancien en un nom FIXE (.old). Si un
processus tournait encore depuis ce .old (mise a jour precedente), le fichier
n'etait ni supprimable ni ecrasable : le renommage sortait en "Acces refuse"
(errno 5), que os.IsPermission rapporte comme un defaut de DROITS. L'UI
affichait donc "droits insuffisants, relance en administrateur", conseil faux :
aucun privilege ne remplace l'image d'un executable en cours d'execution.
- renameAside() ecarte sous un nom UNIQUE (.old-<horodatage>) : le renommage
passe meme si un ancien ecartement est verrouille (verifie sur banc d'essai
avec deux processus vivants)
- les trois endroits qui faisaient la manoeuvre l'utilisent (update, install,
premier lancement), et le menage ramasse le nom fixe herite + les uniques
- message d'erreur : Windows renvoie le meme code pour "droits insuffisants" et
"fichier utilise", les deux causes sont donc nommees
Aussi : la section Cartes graphiques restait affichee avec une seule carte.
L'attribut hidden etait sans effet, .pe-group{display:flex} l'emportant sur la
regle par defaut du navigateur.
- moteur precompile : la version installee est celle qui tourne (on elisait le
dossier le plus ancien), et les anciennes extractions sont purgees
- presets : le moteur precompile reste reconnu apres une mise a jour, et un BIN
pointant une release disparue suit la version installee au lieu d'echouer
- build CUDA : le toolkit est cherche avant le nvcc du PATH, sa racine est
passee a CMake (fin du "CUDA Toolkit not found" avec CUDA installe)
- job d'installation : etat persiste sur disque, une operation interrompue par
un redemarrage du service est annoncee, pastille de rappel sur mobile
- editeur de modele : section Cartes graphiques (--device / --tensor-split), la
liste vient du moteur du preset car les identifiants dependent du backend
- reglages : plus de menu replie, interrupteurs regroupes, decodage speculatif
- CUDA_VISIBLE_DEVICES et WEB_ENGINE survivent au changement de preset, sauf si
le preset les definit lui-meme
Cookie jar en memoire (les murs posent un cookie puis redirigent), en-tetes
DNT et Sec-GPC, et cookies marquant le bandeau comme traite. Les valeurs
envoyees signalent un REFUS du pistage, jamais une acceptation : le but est
de lire la page, pas d'ouvrir des traceurs au nom de l'utilisateur.
Mesure : reuters.com passe de HTTP 401 a 2318 caracteres extraits, aucune
regression sur lemonde/lefigaro/20minutes/theguardian/spiegel/wikipedia.
Moteur web integre en pur Go (http + readability + html-to-markdown),
selectionnable par WEB_ENGINE. Crawl4AI reste disponible pour le rendu
JavaScript et reste le defaut des installations qui l'ont deja configure.
Le schema de web_open n'annonce plus actions/wait_for/dismiss_popups avec
le moteur integre, et une page riche en HTML mais sans texte est diagnostiquee
comme rendue en JavaScript, pour que le modele change de source au lieu de
rouvrir la meme URL en boucle.
Le compactage du contexte detruisait ce dont l'IA avait besoin pour continuer
une recherche, ce qui la faisait boucler ou repartir de zero.
- Compactage : le resume est desormais fabrique a partir du torse ORIGINAL. On
degraissait les resultats d'outils (page web -> marqueur) AVANT de resumer :
le resumeur ne voyait plus aucune information trouvee, donc le resume n'en
contenait aucune et l'IA relancait les memes recherches sans fin. Les
resultats sont seulement raccourcis (1200 car.) pour le resumeur ; le torse
degraisse ne sert plus que de repli si le resume echoue.
- Compactage : la demande EN COURS est preservee telle quelle. Pendant une
boucle d'outils il n'y a aucun message user recent, elle tombait donc dans le
torse et se dissolvait dans le resume, tandis que le TOUT PREMIER message de
la conversation restait epingle en tete : l'IA repondait a la question du
debut et abandonnait la recherche.
- Compactage : prompt du resumeur refait (findings, sources deja consultees,
etat d'avancement) et plafond du resume porte de 1500 a 2200 caracteres.
- Appels repetes : l'avertissement passe EN TETE du resultat et, des la 2e
redemande identique, le contenu n'est plus renvoye. Colle a la fin d'un
resultat de plusieurs milliers de caracteres, il passait inapercu.
- Marqueur d'effacement du compactage : dit explicitement de ne PAS rappeler
l'outil (l'ancien texte se lisait comme une invitation a re-telecharger).
- Outils web : sortie bornee a 8000 caracteres comme le shell. Un
web_read(limit=500) pouvait injecter 25000 caracteres d'un coup et declencher
les compactages en cascade.
- Bulles d'outils : la borne d'affichage passe de 4000 a 12000 caracteres, donc
l'etiquette « ~N tok » cesse d'afficher toujours ~1004 (la valeur du plafond)
et donne la vraie taille. Le chemin « appel identique non rejoue » envoyait
lui le resultat brut sans troncature.
Les skills ont ete fondus dans la memoire, mais les trois chemins
d'installation (Windows, Linux, macOS) creaient toujours un dossier SKILLS
vide.
On cesse de le CREER sans cesser de le LIRE : migrateSkillsToMemory reprend
encore une fois les anciens skills d'une installation existante, et il faut
donc que skillsDir() continue de pointer quelque part. La fonction ne fait
rien quand le dossier est absent.
Rien n'est supprime : un dossier SKILLS existant reste en place, son contenu
ayant deja ete repris dans la memoire.
Verifie sur une installation neuve en bac a sable : plus aucun SKILLS cree.
Un process ne peut pas se relancer lui-meme : tant qu'il tourne, il occupe le
port et tient son propre dossier de donnees. On delegue donc a un
accompagnateur detache — une copie de nous lancee avec une sous-commande
interne — qui attend notre disparition, migre pendant cette fenetre, puis
relance l'application.
C'est cette fenetre qui manquait depuis le debut. Une mise a jour en place
laisse AJEAN tourner, donc le dossier tenu, donc le renommage echoue avec
« Acces refuse » — que Windows renvoie aussi bien pour un verrou que pour un
manque de droits. D'ou des postes bloques sur l'ancien nom malgre 0.7.1 a
0.7.4. Le retour terrain le confirme : la migration n'a abouti qu'en lancant
l'exe telecharge, seul chemin qui arretait les instances avant de migrer.
installedExePath() est relu APRES la migration avant de relancer : le binaire
installe vit dans le dossier de donnees, il change donc de place avec lui, et
relancer l'ancien chemin echouerait. Repli sur le binaire courant si la cible
a disparu — mieux vaut relancer quelque chose que laisser l'utilisateur sans
application.
L'attente est bornee a 30 s. Un depassement n'interrompt pas la suite : la
migration echouera peut-etre et sera retentee plus tard, alors que rester
coince laisserait l'utilisateur sans rien.
Verifie de bout en bout sur banc d'essai : l'accompagnateur attend la
fermeture du process cible, se termine proprement, et l'application est bien
relancee et ressert l'UI.
L'elevation ajoutee en 0.7.3 n'etait jamais atteinte. Elle n'etait cablee que
dans `install` et dans l'installeur de mise a jour (double-clic sur l'exe
telecharge) ; or les utilisateurs font `ajean update` ou cliquent le bouton de
l'interface. restartAfterUpdate ne fait rien sous Windows, et au redemarrage
appFirstRun sort avant d'arriver la (l'application se reconnait comme etant
deja l'installee). Aucun poste ne migrait donc jamais.
postUpdateMigrate est appele apres une mise a jour reussie, cote CLI comme
cote UI web.
Une hypothese a ete invalidee au passage, et elle changeait tout : on croyait
qu'un binaire en cours d'execution empechait de renommer le dossier qui le
contient. C'est faux — Windows verrouille le fichier .exe, pas le nom de ses
dossiers parents. Verifie sur banc d'essai. La migration peut donc se faire
depuis l'application en marche, ce qui rend ce chemin possible.
Consequence non anticipee, traitee ici : le binaire installe vit DANS le
dossier de donnees. Le renommer deplace donc le programme, et laisse un
raccourci du menu Demarrer et une entree de PATH pointant dans le vide.
relinkAfterMigration repointe le raccourci, ajoute le nouveau dossier bin au
PATH et retire l'ancien.
Course de donnees corrigee : retryHomeMigration reinitialisait le cache du
dossier resolu sans verrou, alors qu'il est desormais appele depuis un handler
HTTP pendant que le serveur sert d'autres requetes. sync.Once est remplace par
un RWMutex, et les reinitialisations directes des installeurs Unix passent par
resetResolvedHome.
Un compte non administrateur ne peut pas renommer C:\ProgramData\jean : le
droit manquant porte sur C:\ProgramData. Ces postes gardaient donc l'ancien
nom indefiniment. Les 0.7.1 et 0.7.2 avaient traite le bruit, pas le fond.
L'installation relance desormais AJEAN en administrateur le temps de la
SEULE migration (sous-commande interne, absente de l'aide), puis rend la
main. Un refus de la fenetre UAC est une reponse valable : on continue sur
l'ancien chemin, sans rien casser.
Deux tentatives de discrimination ont echoue avant celle-ci, et le detail
compte pour qui relira ce code :
- Le code d'erreur ne distingue rien. Windows renvoie ERROR_ACCESS_DENIED
aussi bien pour un manque de droits que pour un dossier verrouille par un
programme en cours. Un test le prouve, il avait ete ecrit en croyant
l'inverse.
- Sonder l'ecriture dans le dossier parent ne distingue rien non plus :
ProgramData autorise la creation de fichiers aux utilisateurs standards,
c'est la suppression/renommage d'une entree existante qui est refusee.
C'est donc le LIEU D'APPEL qui selectionne, et lui est fiable : on n'eleve
que depuis `install` et depuis l'installeur de mise a jour, tous deux apres
l'arret des instances. Le cas « verrouille » y est deja ecarte.
Note pour les tests : ne JAMAIS appeler elevateForHomeMigration() sous
`go test`. os.Executable() y designe le binaire de test, que l'elevation
relance — donc toute la suite, en boucle. Constate.
Regression introduite par l'alias de la 0.7.0, signalee en usage : « Une
version plus recente d'AJEAN est deja installee » a CHAQUE lancement, sans
moyen d'en sortir.
Deux defauts qui se renforcaient.
installLegacyAlias utilisait copyExe, qui echoue quand jean.exe est en cours
d'execution — Windows refuse d'ecraser un .exe actif. L'echec etait ignore
volontairement (« sans gravite, la copie repassera au prochain lancement »),
ce qui etait faux : l'alias restait fige indefiniment. replaceExe applique
desormais la technique deja utilisee pour le binaire principal — renommer
l'ancien, ecrire le nouveau, restaurer si la copie echoue. installSelf s'en
sert aussi, pour la meme raison.
ensureShortcuts ne touchait jamais un raccourci existant. Ceux crees avant la
0.7.0 visaient donc toujours jean.exe. Chaque lancement executait l'alias
perime, qui voyait ajean.exe plus recent et le signalait — la boucle. Un
raccourci existant est maintenant repointe s'il vise autre chose que le
binaire courant.
cleanupOldBinary balaie aussi le jean.exe.old que le nouveau remplacement
peut laisser.
Deux tests : remplacement d'un exe verrouille, et garantie que la cible ne
disparait jamais si la copie echoue apres le renommage.
Remonte par un utilisateur Windows non administrateur. Renommer
C:\ProgramData\jean exige d'ecrire dans C:\ProgramData, ce qu'un compte
standard ne peut pas faire : le rename echouait a chaque lancement et le
message technique s'affichait avant CHAQUE commande, y compris `ajean help`.
Rien n'etait casse — le repli sur l'ancien chemin fonctionne comme prevu et
aucune donnee n'est en jeu. Le defaut etait entierement dans l'affichage :
un detail interne presente comme une erreur, sur une situation permanente et
sans consequence.
La raison est desormais enregistree au lieu d'etre imprimee, et ressortie la
ou elle est actionnable : `ajean where`, qui parle justement d'emplacements,
avec la marche a suivre. `ajean install` en administrateur retente la
migration — c'est le seul moment ou les droits sont reunis — et le fait AVANT
de resoudre le dossier, sinon la variable resterait sur l'ancien chemin et on
installerait a cote.
La cause du rename est extraite du *os.LinkError : son texte repete les deux
chemins complets, ce qui donnait trois fois les memes chemins dans un message
qui les cite deja et noyait l'essentiel (« Acces refuse »).
Deux tests : l'echec reste silencieux mais enregistre, et aucun message
parasite quand la migration reussit. Verifie sur un cas reproduit — `help`
est propre, `where` affiche le conseil.
Le renommage des dossiers avait ete repercute dans release.yml mais pas
dans ci.yml, qui compilait encore ./cmd/jean : les deux jobs echouaient.
Une occurrence trainait aussi dans mac-build.yml (cmd/jean/icon.ico), que
le remplacement precedent n'avait attrapee que pour icon.png.
Un cas n'etait pas qu'un commentaire : tools/assemble-ui utilisait
"internal/jean/ui" comme chemin par defaut. La directive go:generate passe
le dossier en argument, donc la generation fonctionnait, mais l'invocation
directe documentee dans son propre en-tete (go run ./tools/assemble-ui)
aurait echoue.
Le reste etait des commentaires designant les anciens chemins, corriges
pour que le depot ne mente plus sur sa propre structure.
Job ci rejoue en entier en local : gofmt, vet, build, tests et les quatre
cross-compilations de release.
nathaninline