@mmmbuto/nexuscrew 0.9.2 → 0.9.4

package/lib/live-host/bridge.js

@@ -17,10 +17,20 @@
 //     fallimento, la risposta è `none` col motivo: la Live parte senza
 //     puntamento, comportamento standard. Un `none` non è un errore HTTP.
 //   - MC2: il prompt per-cella (LIVE_PROMPT.md accanto ai canonici della
-//     cella) viaggia su developerInstructions di thread/start — quindi
-//     SOSTITUISCE l'iniezione globale per quella Live (rev4 LC2 emendata da
-//     rev5 MC2). Se manca non si passa nulla e l'app-server applica la sua
-//     catena globale/default: nessun gradino è un errore (MC2.4).
+//     cella) viaggia su developerInstructions di thread/start e SOSTITUISCE
+//     le developer instructions della config per quella Live (rev4 LC2
+//     emendata da rev5 MC2). La riga che decide è in codex-rs
+//     core/src/config/mod.rs: `developer_instructions.or(cfg.developer_
+//     instructions)` — l'override Some scarta il valore di config. R2
+//     (2026-08-16, verso corretto dopo audit pre-release): l'identità della
+//     cella designata viaggia SEMPRE come intestazione anteposta al campo,
+//     anche senza prompt. Il campo NON è additivo: una cella senza
+//     LIVE_PROMPT.md, che prima non passava nulla e riceveva le developer
+//     instructions della config, ora passa la sola intestazione e QUELLE
+//     NON le riceve più. Restano fuori da questa sostituzione AGENTS.md e
+//     il world state (fragment user, canale separato) e il prompt base.
+//     La via designata per le istruzioni di lavoro della Live è il
+//     LIVE_PROMPT.md della cella: viaggia nello stesso campo.
 //   - MC3: il ponte crea le proprie conversazioni con thread/start e non
 //     tocca MAI la thread di una TUI — né turn/start né thread/resume: chi
 //     guarda i metodi visti dal server deve vedere solo initialize,
@@ -62,21 +72,41 @@ const CLIENT_NAME = 'nexuscrew-live-bridge';
 const ORPHAN_GRACE_MS = 1500;
 
 // —— Prompt per-cella (rev4 LC2, nome fisso confermato da Dev 2026-08-15) ——
-// Collocazione: filesRoot/cloud-<Cella>/LIVE_PROMPT.md. Tre esiti DISTINTI,
-// perché «file non c'è» e «c'è ma non si può leggere» portano chi indaga in
-// posti diversi:
-//   applied:true                  → il testo va su developerInstructions
-//   applied:false, reason missing → ENOENT: assenza legittima (LC2.3), si
-//                                   procede senza, l'app-server applica il
-//                                   proprio gradino globale
+// Collocazione: filesRoot/<tmuxSession>/LIVE_PROMPT.md — la sessione tmux
+// ESATTA che il roster dichiara per la cella designata, la stessa fonte gia'
+// usata per l'intestazione R2 (identityHeader). NON un prefisso ricostruito a
+// mano: fino al 2026-08-16 questa funzione anteponeva 'cloud-' come default
+// universale quando il cellId non ce l'aveva gia' — su un device che chiama
+// le proprie sessioni con un prefisso diverso il file non veniva MAI trovato,
+// e l'esito era 'missing' ("assenza legittima"): il bug si mascherava
+// esattamente nel ramo che avrebbe dovuto segnalarlo. Bug trovato scrivendo
+// docs/LIVE_PROMPT.md, corretto qui.
+//
+// Quattro esiti DISTINTI, perché «non so nemmeno dove cercare», «ho cercato
+// e non c'è» e «c'è ma non si può leggere» portano chi indaga in posti
+// diversi:
+//   applied:true                        → il testo va su developerInstructions
+//   applied:false, reason session-unknown → il roster non dichiara la sessione
+//                                   tmux per questa cella: NESSUN path viene
+//                                   costruito (mai un prefisso indovinato),
+//                                   quindi non si tenta nemmeno la lettura
+//   applied:false, reason missing       → ENOENT sul path dichiarato: assenza
+//                                   legittima (LC2.3), si procede senza
+//                                   PROMPT (R2: l'intestazione identità
+//                                   viaggia comunque). ATTENZIONE: il campo
+//                                   developerInstructions viene comunque
+//                                   inviato per via dell'intestazione, e il
+//                                   consumer lo SOSTITUISCE alla propria
+//                                   configurazione invece di sommarlo — chi
+//                                   non ha prompt per-cella non riceve le
+//                                   developer instructions globali che
+//                                   riceveva prima (vedi MC2, verificato
+//                                   sulla riga che decide)
 //   applied:false, reason unreadable|empty → presente ma inutilizzabile: va
 //                                   dichiarato, mai silenziato
-function readCellPrompt(filesRoot, cellId) {
-  // Il canonico per-cella vive in filesRoot/cloud-<Cella>/. L'id cella arriva
-  // sia senza prefisso (fleet id) sia con (nome sessione tmux): si normalizza
-  // qui, una volta sola.
-  const dirName = String(cellId).startsWith('cloud-') ? String(cellId) : `cloud-${cellId}`;
-  const file = path.join(filesRoot, dirName, 'LIVE_PROMPT.md');
+function readCellPrompt(filesRoot, tmuxSession) {
+  if (typeof tmuxSession !== 'string' || !tmuxSession) return { applied: false, reason: 'session-unknown' };
+  const file = path.join(filesRoot, tmuxSession, 'LIVE_PROMPT.md');
   let raw;
   try {
     raw = fs.readFileSync(file, 'utf8');
@@ -89,6 +119,22 @@ function readCellPrompt(filesRoot, cellId) {
   return { applied: true, source: 'LIVE_PROMPT.md', text };
 }
 
+// —— Identità della Live (R2, 2026-08-16): la porta il ponte, non il prompt ——
+// Il ponte ha la designazione IN MANO (MC3.4: è la sua condizione di
+// funzionamento) e un prompt può legittimamente mancare (MC2.4): se
+// l'identità dipendesse dal prompt, l'assenza del prompt diventerebbe assenza
+// di identità — è esattamente il difetto visto sul campo (la voce andava a
+// leggere tmux per capire dove si trovava).
+//
+// Il fatto, niente di più: quale cella (id Fleet) e, se il roster la dichiara,
+// la sessione tmux esatta — quella con cui la voce raggiunge i canonici della
+// cella in ~/NexusFiles/<tmuxSession>/. Non un'instruzione di lavoro: quelle
+// vivono nel prompt per-cella, che questa intestazione PRECEDE sempre.
+function identityHeader(cellId, tmuxSession) {
+  const sessione = tmuxSession ? ` (sessione tmux ${tmuxSession})` : '';
+  return `Live NexusCrew agganciata alla cella ${cellId}${sessione}.`;
+}
+
 // —— Client on-demand del socket di controllo (sezione protocollo sopra) ——
 // Una sola richiesta per connessione: aperta, handshake, thread/start, chiusa.
 // Le eventuali notifiche broadcast che arrivano nel frattempo vengono ignorate
@@ -308,7 +354,9 @@ function createLiveBridge({
     // qualunque altro engine la Live lavora ATTRAVERSO la cella e il ponte non
     // ha nulla da creare qui.
     const engine = String(cell.engine || '');
-    const prompt = readCellPrompt(root, snap.hostCell);
+    // Stessa fonte dell'intestazione qui sotto: la sessione tmux che il
+    // roster dichiara, mai il cellId ricostruito con un prefisso indovinato.
+    const prompt = readCellPrompt(root, cell.tmuxSession);
 
     if (!engine.startsWith('codex-vl')) {
       const out = {
@@ -322,12 +370,21 @@ function createLiveBridge({
       return out;
     }
 
+    // R2: l'identità viaggia SEMPRE, anteposta al prompt quando c'è. Il campo
+    // non è mai più assente: senza LIVE_PROMPT.md porta la sola intestazione
+    // — e poiché il campo SOSTITUISCE le developer instructions della config
+    // (vedi MC2: la .or() in config/mod.rs), quella cella non le riceve più.
+    const intestazione = identityHeader(snap.hostCell, cell.tmuxSession);
+    const developerInstructions = prompt.applied
+      ? `${intestazione}\n\n${prompt.text}`
+      : intestazione;
+
     let started;
     try {
       started = await startThreadOnControlSocket({
         socketPath: cfg.liveBridgeSocketPath,
         cwd: cell.cwd,
-        developerInstructions: prompt.applied ? prompt.text : undefined,
+        developerInstructions,
         timeoutMs: cfg.liveBridgeTimeoutMs,
         WebSocket,
         log,
@@ -347,12 +404,15 @@ function createLiveBridge({
       at: now(),
     };
     // LC1.4: il puntamento è visibile lato nostro — log con cella, thread e
-    // prompt applicato. È il "dirottamento dichiarato" del contratto.
-    log(`[live-bridge] Live puntata su ${snap.hostCell}: thread ${started.threadId} (cwd ${started.cwd}, prompt ${prompt.applied ? 'per-cella applicato (sostituisce il globale)' : `non applicato (${promptEcho.reason})`})`);
+    // prompt applicato. È il "dirottamento dichiarato" del contratto. Il
+    // campo SOSTITUISCE le developer instructions della config (MC2, la
+    // .or() in config/mod.rs): il log lo dichiara, perché chi lo legge sappia
+    // cosa quella Live NON riceve.
+    log(`[live-bridge] Live puntata su ${snap.hostCell}: thread ${started.threadId} (cwd ${started.cwd}, identità nell'intestazione, prompt ${prompt.applied ? 'per-cella applicato' : `non applicato (${promptEcho.reason})`}, sostituisce le developer instructions di config)`);
     return out;
   }
 
-  return { resolveForLive, readCellPrompt: (cellId) => { const { text, ...rest } = readCellPrompt(root, cellId); return rest; } };
+  return { resolveForLive, readCellPrompt: (tmuxSession) => { const { text, ...rest } = readCellPrompt(root, tmuxSession); return rest; } };
 }
 
 let cachedVersion = null;

package/lib/nodes/peer-transitions.js

@@ -0,0 +1,81 @@
+'use strict';
+// lib/nodes/peer-transitions.js — registra SOLO le transizioni di stato dei
+// peer sul registro diagnostico GIA' esistente (lib/diagnostics/store.js):
+// nessun nuovo store, nessun flusso nuovo, nessun polling in piu'. La salute
+// federata (lib/nodes/health.js) viene gia' sondata a ogni richiesta della UI
+// (/api/nodes, /api/peers) e il risultato veniva buttato via.
+//
+// Misurato il 2026-08-07: un nodo giu' per 25 minuti produceva ZERO record
+// (nextSeq: 1, retained: 0). Senza storia delle transizioni, quando qualcosa
+// cade non si puo' sapere QUANDO e' caduto ne' QUANTE VOLTE.
+//
+// TUNNEL e SERVIZIO restano DUE FATTI DISTINTI, mai un booleano «online»: il
+// caso reale che ha fatto perdere quattro ore era tunnel su + servizio giu'
+// (ECONNRESET, listener vivo ma NexusCrew morto sul dispositivo) contro
+// nessun listener affatto (ECONNREFUSED) — due guasti, due rimedi diversi,
+// e un valore unico li avrebbe fatti cercare nel posto sbagliato.
+//
+// SOLO SULLA TRANSIZIONE: un peer stabile per N sonde produce ZERO record,
+// indipendentemente da quante volte viene sondato. Scrivere a ogni sonda
+// trasformerebbe il registro in rumore e la storia si perderebbe nel volume
+// — peggio di oggi, perche' sembrerebbe di avere i dati.
+//
+// warn, non info: il registro diagnostico scarta 'info'/'debug' quando il
+// verbose non e' acceso (lib/diagnostics/store.js) — e il verbose non si puo'
+// accendere retroattivamente su un incidente gia' successo. Una transizione
+// di peer deve restare visibile anche senza averlo previsto in anticipo, sia
+// che vada verso un guasto sia che torni a posto: solo cosi' si puo'
+// ricostruire QUANDO e' caduto e QUANDO e' tornato, per contare gli episodi.
+const last = new Map(); // nodeName -> { tunnel, service }
+
+function tunnelStateOf(health) {
+  return health && typeof health.transport === 'string' ? health.transport : 'unknown';
+}
+
+// Il servizio si valuta SOLO quando il tunnel e' su: senza trasporto, auth e
+// reachability restano 'unknown' per costruzione (probeHealth non li tocca
+// nel ramo down, vedi lib/proxy/federation.js) — dichiarare qui un servizio
+// "giu'" sarebbe un secondo guasto INVENTATO, non misurato: il tunnel giu'
+// spiega gia' da solo perche' il servizio non e' raggiungibile.
+function serviceStateOf(health) {
+  if (!health || health.transport !== 'up') return 'unknown';
+  if (health.auth === 'ok' && health.reachability === 'ok') return 'ok';
+  if (health.auth === 'failed') return 'auth-failed';
+  if (health.reachability === 'failed') return 'unreachable';
+  return 'unknown';
+}
+
+// nodeName: chiave stabile del peer (node.name in lib/nodes/store.js).
+// health: l'oggetto {transport, auth, reachability, ...} gia' calcolato da
+// lib/nodes/health.js — questa funzione non sonda nulla, consuma soltanto.
+// diagnostics: {record(level, component, code, message, meta)} — vedi
+// lib/diagnostics/store.js. Chiamata ripetutamente con lo stesso stato: dopo
+// la prima volta, silenzio.
+function recordPeerTransition(nodeName, health, diagnostics) {
+  if (!nodeName || !diagnostics || typeof diagnostics.record !== 'function') return;
+  const tunnel = tunnelStateOf(health);
+  const service = serviceStateOf(health);
+  const previous = last.get(nodeName);
+  last.set(nodeName, { tunnel, service });
+  if (!previous) return; // primo probe di questo peer: nessuna "transizione" da niente.
+
+  const tunnelChanged = previous.tunnel !== tunnel;
+  if (tunnelChanged) {
+    diagnostics.record('warn', 'peer-health', 'TUNNEL_TRANSITION',
+      `${nodeName}: tunnel ${previous.tunnel} -> ${tunnel}`,
+      { node: nodeName, state: tunnel });
+  }
+  // Testabile solo quando il tunnel e' su ORA: se e' appena caduto, il
+  // servizio e' passato a 'unknown' come artefatto del tunnel (gia' segnalato
+  // sopra), non come un fatto nuovo — quindi qui non si scrive nulla.
+  if (tunnel === 'up' && previous.service !== service) {
+    diagnostics.record('warn', 'peer-health', 'SERVICE_TRANSITION',
+      `${nodeName}: service ${previous.service} -> ${service}`,
+      { node: nodeName, state: service });
+  }
+}
+
+// Per i test: azzera la memoria delle transizioni fra un caso e l'altro.
+function clearPeerTransitions() { last.clear(); }
+
+module.exports = { recordPeerTransition, clearPeerTransitions, tunnelStateOf, serviceStateOf };

package/lib/proxy/panel-proxy.js

@@ -89,9 +89,23 @@ function stripLocalTokenQuery(search) {
 // sessione del control plane, esattamente cio' che l'Authorization rimossa
 // doveva impedire. E `x-forwarded-*` da un client sono valori che un pannello
 // potrebbe credere veri. Rilievo di un audit indipendente.
-function isStrippedRequestHeader(key) {
+function isStrippedRequestHeader(key, value) {
   if (HOP_BY_HOP.has(key)) return true;
-  if (key === 'authorization' || key === 'cookie' || key === 'host') return true;
+  if (key === 'cookie' || key === 'host') return true;
+  // `authorization` NON si strippa in blocco: lo schema dice di chi e'.
+  //
+  // `Bearer` e' il nostro token del control plane e non deve mai raggiungere il
+  // container — e' la ragione per cui questo strip esiste. Ma un pannello
+  // protetto da password risponde `401 WWW-Authenticate: Basic`, il browser
+  // chiede le credenziali all'utente e le rimanda: buttando via ANCHE quelle,
+  // il pannello ripresentava il prompt all'infinito e il login era impossibile
+  // per costruzione. Sono credenziali che l'utente ha inserito PER il pannello,
+  // in risposta a una sua richiesta: appartengono a lui.
+  //
+  // Dichiarato: se qualcuno mette una basic auth propria davanti a NexusCrew,
+  // quella credenziale raggiungerebbe il pannello. Non e' il nostro schema di
+  // autenticazione e non e' una configurazione che produciamo.
+  if (key === 'authorization') return !credenzialeDelPannello(value);
   // `referer` porterebbe il ticket d'ingresso (viaggiava in query sulla prima
   // richiesta dell'iframe) fino al pannello: al container non deve arrivare
   // NESSUNA credenziale, nemmeno di seconda mano.
@@ -101,10 +115,23 @@ function isStrippedRequestHeader(key) {
   return false;
 }
 
+// ELENCO CHIUSO di cio' che si inoltra, non di cio' che si toglie: un valore
+// sconosciuto non deve poter passare per omissione. Sono gli schemi con cui un
+// server web chiede le credenziali al browser — quelli che l'utente puo' aver
+// inserito in risposta a un `401` del pannello. Tutto il resto, `Bearer`
+// compreso, resta di qua.
+const SCHEMI_DEL_PANNELLO = /^(basic|digest|ntlm|negotiate)\s/i;
+
+function credenzialeDelPannello(value) {
+  const primo = Array.isArray(value) ? value[0] : value;
+  if (typeof primo !== 'string') return false;
+  return SCHEMI_DEL_PANNELLO.test(primo.trim());
+}
+
 function forwardHeaders(headers, targetHost) {
   const out = {};
   for (const [k, v] of Object.entries(headers || {})) {
-    if (isStrippedRequestHeader(k.toLowerCase())) continue;
+    if (isStrippedRequestHeader(k.toLowerCase(), v)) continue;
     out[k] = v;
   }
   // L'host deve essere quello della destinazione: un pannello che genera

package/lib/server.js

@@ -19,6 +19,7 @@ const { loadOrCreateToken, verify } = require('./auth/token.js');
 const { requireToken, bearerFrom } = require('./auth/middleware.js');
 const { filesRoutes } = require('./files/routes.js');
 const { createOutboxWatcher } = require('./files/watcher.js');
+const { leggiTelemetria } = require('./files/telemetry.js');
 const VERSION = require('../package.json').version;
 const { transcribe } = require('./voice/transcribe.js');
 const { selectProvider } = require('./fleet/provider.js');
@@ -32,6 +33,7 @@ const { fsRoutes } = require('./fs/routes.js');
 const nodesStore = require('./nodes/store.js');
 const nodesTunnel = require('./nodes/tunnel.js');
 const nodesHealth = require('./nodes/health.js');
+const { recordPeerTransition } = require('./nodes/peer-transitions.js');
 const nodesInventory = require('./nodes/inventory.js');
 const { createReverseSlotListeners } = require('./nodes/reverse-slot-listeners.js');
 const reverseRotation = require('./nodes/reverse-rotation.js');
@@ -753,6 +755,10 @@ function createServer(opts = {}) {
           status: working ? (s.status || sample?.status || '') : '',
           outbox: sum[s.name] || { count: 0, latest: 0 },
           preview: sample?.preview ?? null,
+          // Contesto libero e tier usati, dove la cella li pubblica (celle
+          // Claude via statusline). Null per tutte le altre — assenza
+          // legittima, non un trattino: la riga resta com'era.
+          telemetry: leggiTelemetria(cfg.filesRoot, s.name),
         };
       }));
       res.json({ sessions: enriched });
@@ -976,6 +982,11 @@ function createServer(opts = {}) {
       });
       const nodes = view.nodes.map((n, i) => {
         const h = healths[i] || null;
+        // La sonda gia' avviene per servire questa risposta: qui si registra
+        // SOLO se il risultato e' diverso dall'ultimo noto per questo peer
+        // (lib/nodes/peer-transitions.js) — nessun probe in piu', nessun
+        // record se il peer resta invariato.
+        recordPeerTransition(n.name, h, diagnostics);
         return { ...n, tunnel: nodesHealth.tunnelFromHealth(h), health: h };
       });
       res.json({ nodeId: view.nodeId, nodes });
@@ -994,6 +1005,10 @@ function createServer(opts = {}) {
       });
       const extras = new Map(direct.map((node, index) => {
         const health = healths[index] || null;
+        // Stessa registrazione di /nodes: la Map di stato di
+        // peer-transitions.js e' condivisa per nome peer, quindi una
+        // transizione gia' vista da /nodes non produce un secondo record qui.
+        recordPeerTransition(node.name, health, diagnostics);
         return [node.name, { health, tunnel: nodesHealth.tunnelFromHealth(health) }];
       }));
       const topology = await federation.collectLocalTopology({

package/lib/update/runner.js

@@ -6,7 +6,7 @@ const os = require('node:os');
 const path = require('node:path');
 const { execFileSync } = require('node:child_process');
 const {
-  PACKAGE_NAME, parseVersion, scrubError, pidAlive, adoptUpdateLock, releaseUpdateLock, readState, writeState,
+  PACKAGE_NAME, parseVersion, scrubError, adoptUpdateLock, releaseUpdateLock, readState, writeState,
   stableRuntimeDir,
 } = require('./core.js');
 
@@ -36,44 +36,45 @@ async function restartRuntime(opts = {}) {
     }
     mode = 'service';
   } else {
-    // I TUNNEL SI FERMANO PRIMA, come fa il riavvio manuale — e prima qui non
-    // accadeva. `commands.restart` chiama `stopManagedTunnels` sul ramo
-    // gestito (commands.js), quindi il percorso di sopra e' coperto; questo
-    // ramo portatile — quello di un dispositivo senza gestore di servizi —
-    // uccideva il servizio e lasciava vivi i supervisori dei tunnel.
+    // IL PUNTO UNICO DEL RIAVVIO, attraversato anche qui. Fino a qui questo
+    // ramo aveva una sua copia di ogni passo: tunnel fermati con un
+    // try/copy proprio, abbattimento con killPidfile diretto (senza l'attesa
+    // dell'uscita che il riavvio manuale fa), attesa porta inline. Due
+    // copie divergono: la stessa divergenza è stata trovata TRE volte, una
+    // per guasto — l'ultima misurata sul campo (2026-08-07): riavvii a mano
+    // → peer su 2/2, riavvii per aggiornamento → peer giù 2/2, la differenza
+    // era UNA riga. Ora i tunnel si fermano PRIMA dallo STESSO ingresso
+    // (`fermaTunnelPrimaDiRiavviare`, con la policy best-effort di questo
+    // chiamante: il compito principale è aggiornare) e il vecchio processo
+    // si abbatte con la STESSA `stopPortableRuntime` del manuale — kill e
+    // attesa dell'uscita incluse.
     //
-    // COSA PRODUCE, osservato sul campo il 2026-08-07: al riavvio il servizio
-    // nuovo trova un supervisore ancora vivo che non riesce ad attribuirsi
-    // — gli servono runId, uid, start-time e un file di stato concorde — e
-    // allora NON lo ferma e NON ne avvia uno suo (`lib/nodes/tunnel.js`:
-    // «unattributable existing supervisor», «orphan tunnel cleanup failed»).
-    // Il canale inverso resta appeso a un orfano che nessuno riconcilia: il
-    // peer risulta giu' finche' qualcuno non interviene a mano.
-    //
-    // La correlazione che lo ha isolato, misurata su un dispositivo reale:
-    // riavvii via `nexuscrew restart` -> peer su, 2 su 2; riavvii per
-    // aggiornamento automatico -> peer giu', 2 su 2. La differenza fra i due
-    // percorsi era esattamente questa riga.
-    //
-    // Best-effort: un errore nel fermare i tunnel non deve impedire
-    // l'aggiornamento, che e' il compito principale. Ma tacerlo lo
-    // renderebbe irrintracciabile la prossima volta.
-    try {
-      (opts.stopTunnelsImpl || commands.stopManagedTunnels)({ home, platform });
-    } catch (e) {
-      if (opts.log) opts.log(`restart portatile: stop tunnel non riuscito — ${e && e.message ? e.message : e}`);
-    }
+    // COSA PRODUCEVA non fermarli, osservato sul campo: il servizio nuovo
+    // trovava un supervisore ancora vivo che non riusciva ad attribuirsi e
+    // non lo fermava né ne avviava uno suo (`lib/nodes/tunnel.js`:
+    // «unattributable existing supervisor»): il canale inverso restava
+    // appeso a un orfano e il peer risultava giù finché qualcuno non
+    // interveniva a mano.
+    commands.fermaTunnelPrimaDiRiavviare({
+      home, platform,
+      ...(opts.stopTunnelsImpl ? { stopTunnelsImpl: opts.stopTunnelsImpl } : {}),
+      ...(opts.log ? { log: opts.log } : {}),
+    });
     const pidPath = pidf.defaultPidfilePath(home);
     const meta = pidf.readPidfile(pidPath);
     if (meta && pidf.isAlive(meta)) {
-      const stopped = pidf.killPidfile(pidPath);
+      const stopped = (opts.stopPortableImpl || commands.stopPortableRuntime)({ home, platform });
       if (!stopped.killed) throw new Error(`restart portatile fallito: ${stopped.reason || 'processo non arrestato'}`);
+      // Il pid è già stato atteso DENTRO stopPortableRuntime (waitForPidExit);
+      // resta la PORTA, che il kernel può trattenere oltre la morte del
+      // processo: un bind nuovo su porta occupata fa cadere il runtime sul
+      // fallback (server.js EADDRINUSE) — una porta DIVERSA da quella
+      // configurata, con i peer accoppiati rifiutati. Si aspetta la vera
+      // liberazione, non la morte del pid.
       const wait = opts.waitImpl || ((ms) => new Promise((resolve) => setTimeout(resolve, ms)));
       let released = false;
       for (let i = 0; i < 60; i += 1) {
-        const dead = !(opts.pidAliveImpl || pidAlive)(stopped.pid);
-        const free = await (opts.portAvailableImpl || commands.portAvailable)(port);
-        if (dead && free) { released = true; break; }
+        if (await (opts.portAvailableImpl || commands.portAvailable)(port)) { released = true; break; }
         await wait(100);
       }
       if (!released) throw new Error(`restart portatile fallito: porta ${port} non liberata`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mmmbuto/nexuscrew",
-  "version": "0.9.2",
+  "version": "0.9.4",
   "description": "Faithful browser tmux client — attach to live sessions over a real PTY, localhost-only, mobile-easy",
   "main": "lib/server.js",
   "bin": {

package/skills/live/SKILL.md

@@ -83,6 +83,14 @@ owning node, not a retry from the requester.
   with nothing designated still answers `GET` with `hostCell: null` — a valid
   state, distinct from "not permitted to ask".
 
+## The per-cell voice prompt
+
+Once a session lands on a host cell, a native Live (engine `codex-vl*`)
+always sends `thread/start` an identity header naming the designated cell
+and its exact tmux session, and appends a per-cell prompt file's text after
+it when one exists. See [The Live per-cell prompt](../../docs/LIVE_PROMPT.md)
+for where the file goes and the ready-to-copy IT/EN/ES templates.
+
 ## Dependencies
 
 **Bundled:** this is a NexusCrew core feature. No external MCP companion or