L'âme est un fichier suivi : une mise à jour peut effacer les réglages, et le Control Center écrit à un chemin en dur

[phmatray]

Ce qui s'est passé

Pendant l'installation de la v1.7.0, git pull a refusé de tourner dans ~/Work/jarvis :

error: cannot pull with rebase: You have unstaged changes.
error: Please commit or stash them.

$ git status --short
 M SOUL.md

Le seul fichier « sale » du dépôt était l'âme — c'est-à-dire les réglages de persona de l'utilisateur, posés depuis le Control Center. La mise à jour n'y touchait pas, donc un git merge --ff-only est passé sans rien perdre. Mais le réflexe naturel devant ce message, git checkout -- SOUL.md, aurait effacé sans un mot le ton, la voix, la langue, les heures de silence et l'apparence du poisson. Aucune sauvegarde, aucune confirmation, aucune trace.

Pourquoi c'est structurel

SOUL.md est de la donnée utilisateur rangée dans un fichier suivi :

• bin/jarvis:73 — SOUL_FILE="${JARVIS_SOUL:-$JARVIS_DIR/SOUL.md}", donc l'âme vit à la racine du dépôt.
• set_setting (bin/jarvis:352) écrit dedans avec sed -i, et le Control Center fait la même chose de son côté.
• Résultat : dès que l'utilisateur touche un réglage, son arbre est sale pour toujours. Chaque git pull s'y heurte, chaque stash la déplace, chaque checkout -- la détruit.

Le dépôt sait déjà résoudre exactement ce problème, et le dit dans son propre .gitignore :

« Sa mémoire vivante : ce qu'il a vécu ICI, avec CETTE personne. Les en-têtes de ces fichiers sont dans memory/scaffold/ et sont suivis ; memory_init les restaure au premier lancement. »

CONVERSATION.md, FAILURES.md, LEARNED.md, ROUTINES.md, REFLEXES.md suivent tous ce motif. SOUL.md est la seule donnée vivante restée dans le dépôt — et c'est la plus irremplaçable des cinq, parce qu'elle n'est pas reconstructible : une mémoire effacée se réécrit à l'usage, un ton choisi ne revient pas tout seul.

Le second défaut, trouvé en chemin

plugin/ControlCenterModule.qml:53 :

readonly property string soulPath: Quickshell.env("HOME") + "/Work/jarvis/SOUL.md"

Le chemin est en dur. Or install.sh copie le greffon dans ~/.config/omarchy/plugins/macarchy.jarvis, donc il ne suit pas le checkout. Deux conséquences :

1. Un utilisateur qui clone ailleurs que ~/Work/jarvis a un Control Center dont chaque sed -i vise un fichier inexistant. Les pilules changent à l'écran, rien n'est écrit, et omarchy-jarvis reset est quand même lancé — donc la conversation est jetée pour un réglage qui n'a pas pris.
2. C'est le seul endroit du code qui ignore JARVIS_SOUL, que tout le reste honore.

Ce qui corrigerait les deux

Descendre l'âme dans le motif que le dépôt applique déjà partout ailleurs :

• SOUL.md → memory/scaffold/SOUL.md (le gabarit, suivi).
• L'âme vivante à côté de la mémoire vivante, gitignorée, restaurée par memory_init au premier lancement comme les sept autres.
• SOUL_FILE pointe là ; JARVIS_SOUL continue de le déplacer pour les tests.
• Le Control Center demande le chemin à omarchy-jarvis au lieu de le supposer — jarvis status sait déjà répondre en clé=valeur, une ligne soul= suffit et supprime le chemin en dur.
• Migration pour les installations existantes : au premier lancement, si l'ancien SOUL.md du dépôt diffère du gabarit, il est déplacé vers le nouvel emplacement, jamais écrasé — c'est la persona de quelqu'un.

Ce que ça vaut

Tant que ce n'est pas fait, chaque mise à jour est un endroit où quelqu'un peut perdre son Jarvis d'un checkout réflexe. Aujourd'hui ça n'est pas arrivé parce que le diff entrant ne touchait pas SOUL.md — la prochaine fois, rien ne le garantit.

omarchy-jarvis doctor

✓ claude (le cerveau)
✓ voxtype (l'oreille)
✓ pw-record
✓ pw-play
✓ piper : une synthèse réelle
✓ voix anglaise
✓ micro présent
✓ daemon wake (hey Jarvis)
✓ venv wake + openwakeword
✓ planches du poisson
✓ poisson conforme à l'âme
✓ greffon installé
✓ unités systemd installées et actives
✓ omarchy-jarvis pointe sur ce dépôt
✓ boîte ~/Jarvis
✓ symlink memory
✓ settings.json valide
✓ table des réflexes bien formée
✓ prompts (ronde, rêve, digestion)
✓ connaissance à jour (omarchy)
✓ état : idle

Tout vert — le défaut n'est pas une panne, c'est une pièce rangée au mauvais endroit.

Trouvé en installant la v1.7.0.