- 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
- 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
- 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
Surface visible passee en AJEAN : aide de la CLI, messages, invite du chat
terminal, commentaires, README, metadonnees Windows du binaire
(InternalName / OriginalFilename).
Les reglages s'appellent desormais AJEAN_* (AJEAN_HOME, AJEAN_MODEL_DIRS,
AJEAN_DL_CONNS, AJEAN_LINK_URL, AJEAN_ACME_EMAIL, AJEAN_SERVICE), avec
l'ancien nom JEAN_* toujours lu en second via envAny(). Ces variables sont
posees a la main dans des shells, des units, des docker-compose et des
scripts de deploiement qu'on ne peut pas retrouver : cesser de les lire
ferait retomber silencieusement un reglage sur sa valeur par defaut.
Migration one-shot du dossier de donnees retentee dans la fenetre ou
l'installateur Windows a arrete toutes les instances, seule fenetre ou le
rename peut aboutir. Le chemin du binaire est recalcule juste apres, sinon
on reinstallerait dans le dossier qu'on vient de deplacer.
Deux choses volontairement NON renommees, parce que les renommer casserait
des utilisateurs sans rien apporter :
- "model": "jean", le nom expose sur l'endpoint compatible OpenAI. Des
integrations externes le configurent en dur.
- les cles localStorage (jean-theme, jean.sys...). Les renommer
reinitialiserait theme, preferences d'affichage et prompt systeme dans le
navigateur de chaque utilisateur.
Le plist launchd recevait /usr/local/bin/jean en dur : le chemin est
desormais injecte, sinon le daemon macOS aurait refuse de demarrer apres le
renommage.
index.html regenere depuis ui/src via go generate.
Socle du renommage jean -> AJEAN, sans aucun impact visible pour le parc
installe. Trois briques :
- module github.com/nathaninline/ajean, cmd/ajean, internal/ajean,
package ajean. Purement interne.
- AjeanHome() remplace JeanHome(). Les defauts deviennent
%ProgramData%\ajean et /etc/ajean, avec migration du dossier existant
au premier lancement. La migration est un os.Rename dans le dossier
parent de l'ancien chemin : intra-volume, donc atomique et instantane
meme avec des .gguf de plusieurs dizaines de Go. Si le rename echoue
(handle ouvert sous Windows, droits, volume en lecture seule) on
CONTINUE sur l'ancien chemin et on retentera : jamais de copie, jamais
de suppression, le pire cas est "rien n'a bouge".
$AJEAN_HOME et $JEAN_HOME restent tous deux honores, ainsi que
/etc/default/ajean et /etc/default/jean : un chemin impose a la main
est un ordre, on ne le migre pas.
- l'auto-MAJ accepte desormais ajean-<os>-<arch> ET jean-<os>-<arch>,
dans cet ordre. Indispensable dans les deux sens : les binaires deja
installes ne connaissent que jean-*, et ce binaire-ci doit pouvoir
s'installer depuis une release anterieure au renommage.
Couvert par des tests, dont le repli quand un handle ouvert bloque le
rename sous Windows.
nathaninline