La conversation est un objet en memoire persiste dans conversation.json :
deux process qui la servent = deux fils divergents qui s'ecrasent. Sous
Linux le service jean-link sert deja les DEUX surfaces (UI locale :8090 +
tunnel) pour cette raison ; le worker detache ajoute en v0.5.4 rompait ce
principe sur Mac/Windows -> conversations differentes entre le local et
app.ajean.link.
L'app fait desormais tourner le tunnel dans son propre process, avec le
MEME mux que l'UI locale, et supprime au demarrage tout worker detache
rescape. Corollaire assume : l'acces distant vit tant que l'app est ouverte
(sur un portable qui s'endort, c'etait deja le cas en pratique).
Le worker est detache expres pour survivre a la fermeture de Jean.app : un
worker lance par une ancienne copie (translocatee ou version precedente)
continue donc de servir l'UI distante avec du code perime — l'alerte App
Translocation s'affichait sur app.ajean.link alors que l'app locale tournait
bien depuis /Applications.
Le fichier PID porte desormais le binaire d'origine en 2e ligne ; au
demarrage, un worker dont le binaire differe du notre est redemarre.
linkServiceCtl/linkServiceActive etaient Linux-only : sur un Mac le token
etait bien enregistre mais rien ne composait jamais le tunnel, d'ou le
message << service arrete >> permanent. Hors Linux on lance desormais
'jean link serve' en processus detache suivi par un fichier PID
(spawnDetached/pidAlive/killTree, nouvelles primitives par plateforme).
- le mode app relance le tunnel au demarrage si une cle est enregistree
- nouvelle route POST /api/link/start + bouton << demarrer le tunnel >>
dans le panneau, visible quand le lien est configure mais arrete
nathaninline