@mmmbuto/nexuscrew 0.9.16 → 0.9.17

package/lib/fleet/managed.js

@@ -103,7 +103,7 @@ function declaredFor(extraModels, profileId, model) {
 // uno la dimentichi perche' un modello dichiarato smetta di essere valido
 // proprio nel punto che conta — l'avvio.
 //
-// D2: Map<engine, Map<id, model>> — porta il descrittore intero, non solo
+// da revisione: Map<engine, Map<id, model>> — porta il descrittore intero, non solo
 // l'id (stesso motivo del commento gemello in definitions.js: extraModels e'
 // costruita due volte, una dentro parseDefinitions per il parsing, una qui per
 // il runtime che rilegge le definizioni gia' salvate; le due DEVONO restare
@@ -767,7 +767,7 @@ function binaryCandidates(client, home) {
 // (non possiamo dichiararlo "trovato"); ma chi costruisce il messaggio
 // (describeManaged) puo' ora distinguere "client non trovato" da "non ho potuto
 // verificare un candidato" — il discriminante e' CHI ha fallito, non che ci sia
-// stata un'eccezione. Stesso principio gia' applicato in checkTermuxExec (3134d2f).
+// stata un'eccezione. Stesso principio gia' applicato in checkTermuxExec.
 function findBinary(client, home, out) {
   const blocked = Array.isArray(out && out.blocked) ? out.blocked : null;
   for (const candidate of binaryCandidates(client, home)) {
@@ -1061,7 +1061,7 @@ function describeManaged(spec, cfg = {}) {
   const extraModels = cfg.extraModels || null;
   const normalized = normalizeManagedSpec(spec, { extraModels });
   if (!normalized) {
-    // D2: il rifiuto resta (i descrittori NON appartengono al profilo di una
+    // da revisione: il rifiuto resta (i descrittori NON appartengono al profilo di una
     // cella: vengono dalla definizione dell'ENGINE, in `d.models` — due
     // soggetti diversi, mescolarli renderebbe ambiguo chi dichiara cosa). Ma
     // se la causa e' proprio questa, il messaggio generico "invalid managed
@@ -1238,7 +1238,7 @@ function sharedMcpArgs(home) {
 // indicizzato sul percorso assoluto — ed e' reale: su questa installazione nove
 // progetti ne hanno, fra cui la directory di lavoro delle celle. Dimenticarlo
 // significava che un elenco parziale non negava server che la sessione carica
-// davvero, e l'operatore avrebbe creduto di averli esclusi. Trovato dall'audit.
+// davvero, e l'operatore avrebbe creduto di averli esclusi. Trovato da una revisione.
 //
 // RESTANO FUORI, e non sono enumerabili da qui: plugin, connettori claude.ai e
 // la configurazione gestita di sistema. Per quelli l'unica esclusione certa e'
@@ -1356,7 +1356,7 @@ function ensurePrivateClaudeConfig(home, profileId, label, penguinMode) {
   return configDir;
 }
 
-// D2 audit: il file .ts generato NON e' il consumatore — Pi lo E'. Un test che
+// da revisione: il file .ts generato NON e' il consumatore — Pi lo E'. Un test che
 // legge solo il file resta verde su un'estensione che Pi rifiuta a runtime.
 // CONTRATTO REALE che Pi (@earendil-works/pi-coding-agent 0.80.10) impone a
 // ogni modello di `pi.registerProvider(id, {models: [...]})` — fonte:
@@ -1382,13 +1382,13 @@ function toPiModelConfig(m) {
   };
 }
 
-// D2: `declaredModels` (opzionale) sono i descrittori dichiarati per l'ENGINE
+// da revisione: `declaredModels` (opzionale) sono i descrittori dichiarati per l'ENGINE
 // (via declaredModelsFor), per il ramo Pi CUSTOM — stesso motivo/stessa fonte
 // di customCatalogFor, mai letti da `spec.models`. Il ramo Pi NON-custom
 // (profile.piExtension) continua a passare `models` dentro l'oggetto spec-like
 // come sempre: e' un catalogo STATICO cablato nel codice (es. alibaba-token-
 // plan), GIA' nella forma completa che Pi si aspetta — un caso diverso, non
-// toccato dal difetto D2. declaredModels, quando presente, ha priorita', ed e'
+// toccato dal difetto da revisione. declaredModels, quando presente, ha priorita', ed e'
 // sempre passato per toPiModelConfig (mai i descrittori grezzi cosi' come sono).
 function writePiProviderExtension(spec, home, declaredModels) {
   const dir = path.join(home, '.nexuscrew', 'pi-providers');
@@ -1524,7 +1524,7 @@ function vlSystemAppendGate(binary, cfg) {
   return { ok: true };
 }
 
-// D2 (fix definitivo — l'audit del pacchetto aveva bocciato la prima versione:
+// (fix definitivo — una revisione del pacchetto aveva bocciato la prima versione:
 // il test costruiva `spec.models` a mano, e in produzione quel campo non
 // esiste mai). `declaredModels` NON viene da `spec`: i descrittori sono
 // proprieta' della definizione dell'ENGINE (`d.models` del documento), non del
@@ -1614,14 +1614,14 @@ function resolveManagedEngine(engine, cell, cfg = {}) {
   // non basta: la normalizzazione che decide se la cella PARTE e' questa, e
   // senza l'elenco dichiarato un modello legittimo diventa «invalid managed
   // profile» — cioe' una cella che non si avvia per una ragione invisibile.
-  // E' il difetto che l'audit ha ripreso due volte: la vista diceva di si',
+  // E' il difetto che la revisione ha ripreso due volte: la vista diceva di si',
   // il boot diceva di no, e nessun test guardava il boot.
   const spec = normalizeManagedSpec(engine.managed, { extraModels: cfg.extraModels || null });
   const info = describeManaged(spec, cfg);
   if (!spec || !info.configured) return { ok: false, reason: info.reason, info };
   const home = cfg.home || require('node:os').homedir();
   const profile = profileFor(spec.client, spec.provider, spec.credentialProfile || '');
-  // D2: i descrittori dichiarati per QUESTO profilo (client.provider — la
+  // da revisione: i descrittori dichiarati per QUESTO profilo (client.provider — la
   // stessa chiave che declaredFor usa dentro normalizeManagedSpec per
   // validare gli id). Vengono dalla definizione dell'ENGINE (extraModels),
   // MAI da spec: e' il ponte che customCatalogFor/writePiProviderExtension
@@ -1845,7 +1845,7 @@ function resolveManagedEngine(engine, cell, cfg = {}) {
     } else if (spec.provider === 'custom') {
       env[spec.envKey] = cred.value;
       args.push(...codexProviderArgs(spec.providerId, spec.displayName, spec.baseUrl, spec.envKey));
-      // D2: onora `models` (engine definition, già validato) come gli altri
+      // da revisione: onora `models` (engine definition, già validato) come gli altri
       // provider — deriva model_catalog_json e model_context_window, così
       // Codex-VL non ricade sul fallback 272K. Senza `models` -> null (no regressione).
       const customMeta = customCatalogFor(spec, model, declaredModels, home);

package/lib/fleet/prompt-delivery.js

@@ -4,7 +4,7 @@
 // managed conservano il prompt su argv (finding separato) e i custom send-keys
 // conservano injectPrompt legacy senza Enter.
 //
-// Contratto (design audit 0.8.47):
+// Contratto (design della revisione 0.8.47):
 //  - Readiness REALE prima della consegna: il pane viene classificato sul SOLO
 //    viewport visibile (capture-pane -p, mai scrollback -S: su generation>0 lo
 //    scrollback puo' contenere vecchi prompt e marker stale). Auth, consenso

package/lib/fleet/runtime.js

@@ -80,7 +80,7 @@ function createBuiltinRuntime(ctx) {
   // solo — il ponte Live, che la chiede esplicitamente e in-processo — quindi
   // e' lui a doverla chiedere, non tutti gli altri a doversene ricordare.
   // Il backup vieta gia' le cwd assolute per la stessa ragione: sono specifiche
-  // del dispositivo. Rilievo di un audit indipendente.
+  // del dispositivo. Rilievo di una revisione indipendente.
   async function cellStatus({ includeCwd = false } = {}) {
     if (Date.now() - cache.at > STATUS_TTL_MS) {
       reloadDefs();                          // pick-up di edit esterne/file
@@ -100,7 +100,7 @@ function createBuiltinRuntime(ctx) {
       const effectivePolicy = ['pi', 'shell'].includes(engineDef?.managed?.client)
         ? 'standard'
         : (remembered || engineDefault || '');
-      // D8: panelUrl per-cella vince su quello precompilato dall'engine (es.
+      // da revisione: panelUrl per-cella vince su quello precompilato dall'engine (es.
       // desktop.local), che a sua volta e' il default. Stessa forma di
       // engineDef gia' usata sopra per la permission policy: un valore
       // presente qui e' gia' passato da validPanelUrl a monte (parseEngine/
@@ -222,7 +222,7 @@ function createBuiltinRuntime(ctx) {
     // broker-backed supervisor: credentials never enter tmux state/argv and a
     // client that exits after readiness is restarted with bounded backoff.
     // '-P -F #{pane_id}': tmux stampa il pane id della sessione appena creata,
-    // cosi' l'iniezione del prompt bersaglia ESATTAMENTE quel pane (audit impl
+    // cosi' l'iniezione del prompt bersaglia ESATTAMENTE quel pane (da revisione impl
     // #5: elimina la race di riuso del nome sessione tra waitAlive e paste).
     const readyMs = cfg.launchReadyMs != null ? cfg.launchReadyMs : 500;
     const child = composeClientInvocation(launchEngine, cell);

package/lib/live-host/bridge.js

@@ -22,7 +22,7 @@
 //     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
+//     (verso corretto dopo revisione 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
@@ -227,7 +227,7 @@ function readCellPrompt(filesRoot, tmuxSession) {
 // il ponte: il nome esatto della sessione, che il server MCP accetta da
 // NEXUSCREW_MCP_SESSION via stdio. Il valore NON si mette in systemd
 // Environment= (una identità statica condivisa = impersonare una cella
-// fissa, demolito in audit v1): lo dice l'intestazione, per-cella.
+// fissa, demolito in revisione v1): lo dice l'intestazione, per-cella.
 //
 // 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
@@ -497,7 +497,7 @@ function createLiveBridge({
     // Tre condizioni diverse, tre nomi: la designazione dichiarata non
     // eleggibile dall'hub, la cella che non esiste piu' nel roster, e la cella
     // che c'e' ma e' spenta. Un nome solo mandava a guardare l'hub anche quando
-    // il problema era una sessione chiusa. Rilievo di un audit indipendente.
+    // il problema era una sessione chiusa. Rilievo di una revisione indipendente.
     if (snap.eligible !== true) return none('host-ineligible');
 
     let cell;

package/lib/live-host/routes.js

@@ -39,7 +39,7 @@ function isActive(cell) {
   return !!(cell && cell.active === true && cell.tmux !== false);
 }
 
-// --- Seam lease↔designazione (2026-08-15, decisione presa in revisione: grace = false) -----
+// --- Seam lease↔designazione (decisione presa in revisione: grace = false) -----
 //
 // L'idoneita' dell'host designato non e' piu' solo «sessione tmux viva»: con
 // remain-on-exit la sessione sopravvive alla morte del supervisore, e la

package/lib/mcp/server.js

@@ -162,7 +162,7 @@ function resolveIdentity({ env, tmuxBin, execFileImpl }) {
           return settle(missing);
         }
         const name = String(stdout || '').trim();
-        // tmux 3.4, misura dell'audit (probe A1/A2): pane morto con -t ->
+        // tmux 3.4, misura della revisione (probe doppia): pane morto con -t ->
         // rc=0 e stdout VUOTO. Il vuoto è il segnale dello stantio.
         if (!name) return settle(stalePane);
         if (isValidSession(name)) {
@@ -288,12 +288,11 @@ function createMcpServer(opts = {}) {
     return j;
   }
 
-  // NC-R. Aggiornare NexusCrew NON aggiorna il bridge MCP delle celle gia' in
-  // piedi: quel processo e' partito col codice di prima e ci resta fino al
-  // riavvio della cella. Il sintomo e' crudele — si installa una correzione, si
-  // riprova, e si riceve l'errore VECCHIO — e chi lo subisce conclude che la
-  // correzione non funziona. E' successo il 2026-08-07 su rc.26, a me, e ci ho
-  // messo un giro intero a capirlo.
+  // NC-R. Aggiornare NexusCrew NON cambia il codice gia' caricato dai bridge
+  // MCP delle celle attive: ogni processo resta sulla versione con cui e' stato
+  // avviato fino al riavvio della cella. Dopo una correzione installata, un
+  // bridge ancora attivo puo' quindi restituire l'errore precedente; prima di
+  // valutare la correzione vanno confrontate le versioni di hub e bridge.
   //
   // Il momento in cui serve saperlo e' esattamente quello in cui qualcosa
   // fallisce, quindi la verifica sta SOLO sul ramo d'errore: a regime non costa
@@ -367,7 +366,7 @@ function createMcpServer(opts = {}) {
       return replyError(null, INVALID_REQUEST, 'richiesta non valida (atteso oggetto JSON-RPC)');
     }
     const id = (typeof msg.id === 'string' || typeof msg.id === 'number') ? msg.id : undefined;
-    // F6 (audit): SOLO JSON-RPC 2.0 — versione assente/errata -> -32600 anche
+    // da revisione: SOLO JSON-RPC 2.0 — versione assente/errata -> -32600 anche
     // per i messaggi senza id (il no-op vale solo per notification 2.0 valide).
     if (msg.jsonrpc !== '2.0') {
       return replyError(id !== undefined ? id : null, INVALID_REQUEST, 'jsonrpc "2.0" richiesto');

package/lib/mcp/tools.js

@@ -345,7 +345,7 @@ const TOOLS = [
       // Restituirlo cosi' evita di far leggere un successo dove c'e' un rifiuto.
       // Nessun conteggio: il dispatcher non lo propaga, e un ramo che non puo'
       // mai essere vero e' codice morto travestito da informazione
-      // (rilievo R1 di un audit indipendente su rc.14). Se un giorno servira' il dettaglio,
+      // (rilievo di una revisione indipendente). Se un giorno servira' il dettaglio,
       // va fatto propagare da forward(), non dedotto qui.
       if (target) return { status: j.status, ...(j.reason ? { reason: j.reason } : {}) };
       return { delivered: j.delivered };

package/lib/nodes/commands.js

@@ -204,7 +204,7 @@ function nodesAdd(opts) {
 
   log(`nodes add: nodo "${name}" aggiunto (ssh ${ssh}${sshPort ? `:${sshPort}` : ''}, nexus remoto ${remotePort} -> locale ${localPort})`);
   log('Incolla nel ~/.ssh/authorized_keys del NODO (lato forward, chiave dedicata):');
-  // R19: permitopen con le destinazioni EXPLICITE dei -L. Qui si conosce solo
+  // da revisione: permitopen con le destinazioni EXPLICITE dei -L. Qui si conosce solo
   // la porta nexus: la porta pannello del peer la annuncia il JOIN, non
   // esiste ancora — quando apparirà, la riga completa (due destinazioni) la
   // emette il pairing. Mai un permesso generico: è ciò che impedisce a questa
@@ -392,7 +392,7 @@ function nodesRemove(opts) {
   let next;
   try { next = store.removeNode(st, name); }
   catch (e) { log(`nodes remove: ${e.message}`); return { code: 1 }; }
-  // Ferma un eventuale forward tunnel ATTIVO prima di togliere la config (audit F4):
+  // Ferma un eventuale forward tunnel ATTIVO prima di togliere la config (da revisione):
   // senza questo il ssh resterebbe orfano — porta locale aperta verso un nodo che non
   // e' piu' in config, irraggiungibile e senza piu' uno stop pulito via CLI/API.
   let stopped = false;

package/lib/nodes/health.js

@@ -51,7 +51,7 @@ function applyProbeHysteresis(key, probed, previous, now, threshold) {
   // now is simply down — reporting 'unknown' would keep a declared-dead peer
   // out of the down state forever (one probe per process, never reaching the
   // threshold unless someone keeps probing). The hysteresis only exists to
-  // protect a measured up state from jitter, per 239e2e6.
+  // protect a measured up state from jitter, per una revisione precedente.
   return { ...probed, consecutiveFailures: failures };
 }
 

package/lib/nodes/identity.js

@@ -28,7 +28,7 @@
 // secondo scrittore — la proprieta' regge per assenza, non per controllo, e la
 // differenza va detta invece che lasciata credere.
 //
-// Rilievo dell'audit indipendente: una funzione provata e senza chiamanti e' il
+// Rilievo della revisione indipendente: una funzione provata e senza chiamanti e' il
 // segnale piu' forte che una garanzia esista, ed e' il piu' facile da dare per
 // sbaglio.
 const fs = require('node:fs');
@@ -79,14 +79,11 @@ function readKeyFile(p) {
       + 'la chiave privata e\' leggibile oltre il proprietario, va rigenerata a mano');
   }
   // UN FILE CHE ESISTE MA NON E' USABILE FA RUMORE, NON SI SOSTITUISCE.
-  // La prima stesura tornava `null` per uno schema sbagliato — cioe' «genera
-  // pure una chiave nuova» — e LANCIAVA su un JSON corrotto, perche' il parse
-  // stava fuori dal try. Due esiti opposti per due modi di essere illeggibile,
-  // e quello comodo era il piu' pericoloso: rigenerare cambia l'identita' di
-  // questo nodo, e ogni peer che aveva legato la vecchia si ritrova per sempre
-  // con una chiave che non corrisponde. Meglio fermarsi e farlo sapere.
-  // Rilievo dell'audit indipendente; risolto nel verso opposto a quello
-  // proposto, perche' la coerenza va cercata sul ramo sicuro.
+  // Uno schema errato e un JSON corrotto sono due forme dello stesso stato non
+  // usabile: entrambi devono fare rumore e nessuno deve autorizzare una nuova
+  // chiave. Rigenerare cambia l'identita' del nodo e lascia ogni peer gia'
+  // associato con una chiave che non corrisponde. Il ramo sicuro si ferma e
+  // rende esplicita la causa senza sostituire il file.
   let parsed;
   try {
     parsed = JSON.parse(fs.readFileSync(p, 'utf8'));
@@ -136,10 +133,10 @@ function writeKeyFile(p, privateKeyPem) {
 // ensureNodeKey: idempotente. La prima chiamata genera, le successive leggono.
 // `created` distingue i due casi per chi vuole registrarlo una volta sola.
 // `afterWriteSeam` e' un seam di prova, come `sessionExistsSeam` e `fleetSeam`
-// altrove: viene chiamato subito dopo la scrittura e serve a far accadere la
-// corsa in modo deterministico. Senza, il test della corsa e' verde per
-// costruzione — il file esiste gia' e il percorso di CREAZIONE non viene mai
-// eseguito. L'ho scoperto perche' il controllo negativo non falliva.
+// altrove: viene chiamato subito dopo la scrittura e rende deterministico il
+// punto della corsa. Senza il seam, il test puo' osservare un file gia'
+// esistente e non esercitare mai il percorso di CREAZIONE; il controllo
+// negativo deve quindi fissare esplicitamente quel punto.
 function ensureNodeKey({ home, keyPath, afterWriteSeam } = {}) {
   const p = keyPath || keyPathFor(home);
   const existing = readKeyFile(p);

package/lib/nodes/store.js

@@ -80,7 +80,7 @@ function isAbsPath(p) {
 // token remoto: segreto opaco, single-line, cap. Vuoto -> assente (non salvato).
 // Charset ristretto a header-safe (VCHAR + spazio/tab): il token viene iniettato
 // in `Authorization: Bearer <t>` verso l'upstream; un char fuori range farebbe
-// lanciare setHeader in modo sincrono (ERR_INVALID_CHAR). (hardening audit).
+// lanciare setHeader in modo sincrono (ERR_INVALID_CHAR). (hardening).
 function validToken(t) {
   return typeof t === 'string' && t.length > 0 && t.length <= MAX_TOKEN_LEN
     && /^[\x20-\x7e\t]+$/.test(t);
@@ -589,7 +589,7 @@ function initStore(p) {
 }
 
 // Compatibilita' API interna: il vecchio nome non inizializza piu' a runtime.
-// Tenerlo strict impedisce che un call-site dimenticato reintroduca F1.
+// Tenerlo strict impedisce che un call-site dimenticato reintroduca quel difetto.
 function loadOrInitStore(p) { return loadStoreStrict(p); }
 
 // --- Mutazioni pure (ritornano un nuovo store; il caller lo scrive) ---------

package/lib/nodes/tunnel-supervisor.js

@@ -21,7 +21,7 @@ const ownershipGraceMs = Number.isFinite(ownershipGraceRaw) && ownershipGraceRaw
 const reverseFailureMaxRaw = Number(process.env.NEXUSCREW_TUNNEL_REVERSE_FAILURE_MAX || 8);
 const reverseFailureMax = Number.isInteger(reverseFailureMaxRaw) && reverseFailureMaxRaw >= 1
   ? Math.min(reverseFailureMaxRaw, 32) : 8;
-// R19 seguito — contratto per la sonda del canale -L quando non conclude MAI:
+// da revisione — contratto per la sonda del canale -L quando non conclude MAI:
 // continuare a sondare ogni 250ms e' giusto per la finestra transitoria (il
 // servizio remoto non e' ancora su dopo un restart/aggiornamento: la prossima
 // sonda e' una connessione FRESCA, si qualifica da sola appena il servizio
@@ -35,7 +35,7 @@ const reverseFailureMax = Number.isInteger(reverseFailureMaxRaw) && reverseFailu
 // quella soglia il canale entra in degraded, ESATTAMENTE come il fallimento
 // del forward inverso — stesso stato, stessa auto-guarigione a cadenza fissa,
 // mai un "pronto" dichiarato senza averlo verificato (sarebbe la stessa bugia
-// che R19 ha tolto, solo con una bandiera "non verificato" appesa sopra).
+// che una revisione ha tolto, solo con una bandiera "non verificato" appesa sopra).
 const channelProbeMaxRaw = Number(process.env.NEXUSCREW_TUNNEL_CHANNEL_PROBE_MAX || 60);
 const channelProbeMax = Number.isInteger(channelProbeMaxRaw) && channelProbeMaxRaw >= 1
   ? Math.min(channelProbeMaxRaw, 240) : 60;
@@ -112,7 +112,7 @@ function clearForwardProbe() {
 // forces OpenSSH to establish the real forward channel. Only that event may
 // advertise transport-ready or reset retry backoff.
 //
-// R19: connect NON è prova di canale. OpenSSH accetta la TCP sul listener
+// da revisione: connect NON è prova di canale. OpenSSH accetta la TCP sul listener
 // locale SUBITO e chiede il canale al server DOPO: se il server lo nega
 // (permitopen senza quella destinazione) il socket viene CHIUSO nel giro di
 // millisecondi — bind locale riuscito, canale morto. Una finestra di grazia
@@ -159,7 +159,7 @@ function probeForwardChannels({ ports, graceMs = CHANNEL_GRACE_MS, connect = net
   });
 }
 
-// R19 punto 3: chi ha installato la chiave quando il pannello non esisteva è
+// da revisione punto 3: chi ha installato la chiave quando il pannello non esisteva è
 // rotto e NON lo sapeva. Il prodotto lo DICE, con la riga da sostituire: le
 // destinazioni arrivano dagli `-L`, la pubblica si DERIVA dalla privata
 // indicata da `-i`. Quando non si riesce a derivarla, dice comunque COSA
@@ -359,7 +359,7 @@ function enterDegraded(diagnosis) {
   retryTimer = setTimeout(run, steadyRetryMs);
 }
 
-// R19 seguito, secondo difetto (2026-08-17, audit su develop@437d29f):
+// secondo difetto della stessa famiglia (da revisione interna):
 // enterDegraded per il canale -L riusava la macchina del forward inverso
 // senza la sua precondizione implicita. Nel reverse failure `child` e' GIA'
 // null quando enterDegraded gira (handleFailure lo azzera PRIMA, perche' e'
@@ -369,7 +369,7 @@ function enterDegraded(diagnosis) {
 // generazione. run() faceva `child = spawn(...)` incondizionatamente: la
 // vecchia generazione, ancora viva, restava senza piu' nessuna variabile che
 // la referenzi — irraggiungibile da stop(), orfana, titolare dei suoi bind
-// per sempre. Misurato dall'auditor: due fake-ssh vivi dopo un degraded,
+// per sempre. Misurato in revisione: due fake-ssh vivi dopo un degraded,
 // SIGTERM al supervisor ne ferma solo l'ultimo.
 //
 // La correzione non e' locale (un kill dentro enterDegraded): e' che
@@ -525,6 +525,6 @@ function acquireGeneration() {
 }
 if (require.main === module) acquireGeneration();
 
-// Esportate per prova diretta (R19): il main resta argv/env-driven e NON parte
+// Esportate per prova diretta (da revisione): il main resta argv/env-driven e NON parte
 // al require.
 module.exports = { probeForwardChannels, refusalHint, refusalDetails, CHANNEL_GRACE_MS };

package/lib/nodes/tunnel.js

@@ -480,7 +480,7 @@ function supervisorExited(pid, timeoutMs = 2500, impl = {}) {
 // Pre-flight sincrono: l'unico modo di "surfaccare" un binario ssh assente come
 // failure ESPLICITA nel valore di ritorno (lo spawn emette 'error' asincrono, non
 // catturabile sync). spawnSyncImpl iniettabile per test deterministici.
-// ssh -V esiste su ogni platform supportata; ENOENT = binario mancante (audit F2).
+// ssh -V esiste su ogni platform supportata; ENOENT = binario mancante (da revisione).
 function sshBinaryAvailable(sshBin, spawnSyncImpl) {
   try {
     const r = (spawnSyncImpl || spawnSync)(sshBin, ['-V'], { encoding: 'utf8' });
@@ -493,7 +493,7 @@ function sshBinaryAvailable(sshBin, spawnSyncImpl) {
 // nel logfile del tunnel; pidfile con cmd verificabile (kill anti PID-reuse).
 // spawnImpl/spawnSyncImpl iniettabili per i test (mai lancia ssh vero in suite).
 //
-// INVARIANTI (audit F2/F3):
+// INVARIANTI (da revisione):
 //   - MAI crashare: spawn throw, error async, pid mancante -> failure esplicita
 //     {started:false, reason}, con cleanup di pidfile/process/log fd di nostra proprieta'.
 //   - NESSUN leak del log fd aperto internamente: il padre chiude la SUA copia dopo
@@ -558,7 +558,7 @@ function startTunnel(opts) {
   };
 
   // Pre-flight: binario ssh mancante -> failure esplicita, nessuno spawn, nessun
-  // crash (audit F2: prima restituiva started:true e poi l'event 'error' killava Node).
+  // crash (da revisione: prima restituiva started:true e poi l'event 'error' killava Node).
   if (!sshBinaryAvailable(sshBin, spawnSyncImpl)) {
     closeOwnedFd();
     return { started: false, reason: 'ssh binary not found', sshBin };
@@ -630,7 +630,7 @@ function startTunnel(opts) {
   if (Number.isInteger(logFd)) {
     try { fs.writeSync(logFd, `[nexuscrew] supervisor requested transport=${path.basename(sshBin)}\n`); } catch (_) {}
   }
-  closeOwnedFd(); // copia del padre: il figlio ha la sua dup; nessun leak (audit F3)
+  closeOwnedFd(); // copia del padre: il figlio ha la sua dup; nessun leak (da revisione)
   return { started: true, pid, logPath, transport: sshBin };
 }
 
@@ -694,7 +694,7 @@ function readSshVersion(spawnSyncImpl) {
   } catch (_) { return null; }
 }
 
-// R19: la riga authorized_keys con le destinazioni EXPLICITE dei -L. Una sola
+// da revisione: la riga authorized_keys con le destinazioni EXPLICITE dei -L. Una sola
 // porta quando il pannello non è (ancora) noto: nodesAdd non può conoscerla,
 // la annuncia il peer nel join — e allora la riga la emette CHI ha
 // l'informazione (pairing, supervisor). Due permitopen distinti, MAI un
@@ -715,11 +715,10 @@ function authorizedKeysLine({ remotePort, panelRemotePort, pub } = {}) {
 
 // LA PUBBLICA SI DERIVA DALLA PRIVATA, non si legge dal file accanto.
 //
-// Tre giri fa validavo il nome dell'algoritmo, due giri fa la struttura del
-// blob, un giro fa la chiedevo a `ssh-keygen -l` sul file `.pub`. Tutte e tre
-// le volte un audit ha trovato il caso che restava: e l'ultimo lo chiude solo
-// cambiando la domanda. Validare `A.pub` prova che quel file contiene UNA
-// chiave valida — non che sia LA chiave di `A`. Se `A.pub` e' stale, ripristinato
+// Validare il nome dell'algoritmo, la struttura del blob o il risultato di
+// `ssh-keygen -l` su `A.pub` prova soltanto che il file contiene UNA chiave
+// valida — non che sia LA chiave derivata dalla privata di `A`. Se `A.pub` e'
+// stale, ripristinato
 // da un backup o sostituito, si pubblica la chiave sbagliata: l'utente
 // sostituisce la riga di A con quella di B, e al reconnect successivo A perde
 // l'accesso. Il prodotto avrebbe causato il guasto che prometteva di riparare.
@@ -733,7 +732,7 @@ function authorizedKeysLine({ remotePort, panelRemotePort, pub } = {}) {
 // batch non si puo' sbloccare) o `ssh-keygen` non c'e': senza poterla derivare
 // non si compone nessuna riga.
 // Esiti ENUMERATI della derivazione della pubblica (difetto strutturale
-// registrato dall'auditor: `null | stringa` comprimeva stati DIVERSI, e il
+// registrato in revisione: `null | stringa` comprimeva stati DIVERSI, e il
 // livello basso componeva frasi su fatti che non conosce — meta' della 0.9.5
 // e' nata li'). Gli esiti sono DATI, senza testo per l'utente: le frasi si
 // compongono al confine UI/log, mai qui. Si aggancia a P4: una chiave cifrata

package/lib/notify/asks.js

@@ -3,13 +3,13 @@
 // Stato in-memory + persistenza <dir>/asks.json 0600 (sopravvive al restart:
 // un ask aperto resta risponibile). Lo store e' PURO stato: il paste tmux e la
 // notify li orchestra la route (lib/notify/routes.js), che qui fa il ciclo
-// claim -> (paste) -> commit/release (F2: una sola answer puo' vincere).
+// claim -> (paste) -> commit/release (da revisione: una sola answer puo' vincere).
 const path = require('node:path');
 const crypto = require('node:crypto');
 const { readJsonSafe, atomicWriteJson } = require('./persist.js');
 
 const ASKS_FILE = 'asks.json';
-// F5: MAX_OPEN e' un cap DURO sugli ask aperti — al cap il nuovo ask viene
+// da revisione: MAX_OPEN e' un cap DURO sugli ask aperti — al cap il nuovo ask viene
 // RIFIUTATO (reason 'cap'), mai droppato uno aperto. MAX_KEEP pota solo gli
 // answered piu' vecchi dal file.
 const MAX_OPEN = 100;
@@ -72,7 +72,7 @@ function createAsksStore(opts = {}) {
   function create({ question, options, session }) {
     const v = validate({ question, options });
     if (!v.ok) return { ok: false, reason: 'invalid', error: v.error };
-    // F5: cap duro sugli aperti — rifiuto esplicito, MAI drop di ask aperti.
+    // da revisione: cap duro sugli aperti — rifiuto esplicito, MAI drop di ask aperti.
     if (openCount() >= MAX_OPEN) {
       return {
         ok: false,
@@ -103,7 +103,7 @@ function createAsksStore(opts = {}) {
       .map((a) => ({ ...a, ...(a.options ? { options: a.options.slice() } : {}) }));
   }
 
-  // --- ciclo answer F2 (audit): claim atomico open -> answering ---------------
+  // --- ciclo answer (da revisione): claim atomico open -> answering ---------------
   // Node e' single-threaded ma il paste e' un await: due answer concorrenti
   // superavano entrambe il check `answered` prima che una marcasse. Il claim
   // sincrono (nessun await tra check e set) fa vincere UNA sola richiesta; le

package/lib/notify/persist.js

@@ -6,7 +6,7 @@ const fs = require('node:fs');
 const path = require('node:path');
 const crypto = require('node:crypto');
 
-// Legge un JSON (oggetto) da file segreto. Fail-closed (F4 audit): open
+// Legge un JSON (oggetto) da file segreto. Fail-closed (da revisione): open
 // O_NOFOLLOW + fstat sullo STESSO fd (niente race lstat->open), e un file
 // preesistente con symlink, tipo non-regolare, owner inatteso o permessi di
 // gruppo/altri viene RIFIUTATO con errore chiaro — mai riparato in silenzio

package/lib/notify/push.js

@@ -7,7 +7,7 @@
 // Il sender e' iniettabile (webpushImpl) cosi' i test non toccano MAI la rete;
 // la chiave PRIVATA non esce da questo modulo.
 //
-// F7 (audit, threat model SSRF): sendNotification fa una richiesta server-side.
+// da revisione (threat model SSRF): sendNotification fa una richiesta server-side.
 // Ogni endpoint e' https-only, viene risolto sia al subscribe sia immediatamente
 // prima del send, e la richiesta usa un https.Agent con lookup PINNATO agli IP
 // verificati. Cosi' un secondo lookup/DNS rebinding non puo' cambiare destinazione.
@@ -168,7 +168,7 @@ function createPushService(opts = {}) {
   if (!opts.dir) throw new Error('createPushService: dir richiesta');
   const vapidPath = path.join(opts.dir, VAPID_FILE);
   const subsPath = path.join(opts.dir, SUBS_FILE);
-  // F3: closure iniettata dal server — in READONLY questo modulo non scrive MAI
+  // da revisione: closure iniettata dal server — in READONLY questo modulo non scrive MAI
   // (niente generazione VAPID, niente cleanup subscription).
   const readonly = typeof opts.readonly === 'function' ? opts.readonly : () => false;
   const lookupImpl = opts.lookupImpl || dns.promises.lookup;
@@ -191,7 +191,7 @@ function createPushService(opts = {}) {
       vapid = { publicKey: cur.publicKey, privateKey: cur.privateKey };
       return vapid;
     }
-    // F3: la generazione e' una SCRITTURA — vietata in READONLY (503 esplicito,
+    // da revisione: la generazione e' una SCRITTURA — vietata in READONLY (503 esplicito,
     // niente vapid.json fantasma).
     if (readonly()) {
       const e = new Error('READONLY: chiavi VAPID assenti e non generabili (riavvia senza READONLY per il primo setup push)');
@@ -241,7 +241,7 @@ function createPushService(opts = {}) {
   function count() { return readSubs().length; }
 
   // Invia il payload a tutte le subscription. 404/410 (endpoint morto) -> la
-  // subscription si rimuove, MA NON in READONLY (F3: riscrivere push.json e' una
+  // subscription si rimuove, MA NON in READONLY (da revisione: riscrivere push.json e' una
   // scrittura persistente; la notify viene comunque consegnata alle vive).
   // Nessuna subscription -> {sent:0} senza generare VAPID (resta lazy davvero).
   async function sendToAll(payload) {

package/lib/notify/routes.js

@@ -1,7 +1,7 @@
 'use strict';
 // Route del MCP bridge (design §2): notify, web-push, asks. Montate dentro il
 // router /api gia' dietro requireToken (server.js) — qui restano solo:
-//   - READONLY come FLOOR (F3 audit): sono gated 403 TUTTI i mutanti — answer
+//   - READONLY come FLOOR (da revisione): sono gated 403 TUTTI i mutanti — answer
 //     (scrittura PTY via paste), push subscribe/unsubscribe (push.json) e la
 //     CREAZIONE di ask (persiste asks.json e genererebbe domande non
 //     risponibili dallo stesso server). L'UNICA eccezione dichiarata e' la
@@ -9,11 +9,11 @@
 //     push senza persistenza; anche il cleanup delle subscription morte e'
 //     sospeso in READONLY, vedi lib/notify/push.js). Le GET restano lettura
 //     pura: /push/vapid in READONLY non genera chiavi (503 se assenti).
-//   - rate-limit (F1 audit): il campo `session` e' dichiarato dal chiamante e
+//   - rate-limit (da revisione): il campo `session` e' dichiarato dal chiamante e
 //     NON e' un confine di sicurezza — il limite che conta e' GLOBALE per
 //     principal/token (un Bearer = un'installazione); il bucket per-sessione
 //     resta come fairness tra celle oneste. Stessa coppia di limiti sulla
-//     creazione ask (F5).
+//     creazione ask (da revisione).
 //   - validazione input strict fail-closed (schema chiuso per ogni body).
 // Il paste della risposta riusa ESATTAMENTE pasteToSession (bracketed literal,
 // niente Invio, control char rifiutati): qui si sanifica il testo PRIMA.
@@ -43,7 +43,7 @@ const MAX_BODY = 2000;
 const MAX_ANSWER = 3900;
 const MAX_REPLY_LABEL = 48;
 
-// Sliding window in-memory per chiave. La mappa ha un cap duro (F1): entry
+// Sliding window in-memory per chiave. La mappa ha un cap duro (da revisione): entry
 // scadute potate a ogni giro, poi evizione LRU deterministica (ordine di
 // iterazione della Map = ordine di ultimo uso, re-insert ad ogni allow).
 // NB: l'evizione azzera il conteggio del bucket evitto — per questo il cap
@@ -68,7 +68,7 @@ function createRateLimiter({ max = RATE_MAX, windowMs = RATE_WINDOW_MS, maxBucke
   return { allow, size: () => hits.size };
 }
 
-// Coppia di limiti F1/F5: globale per token (confine di sicurezza) + per
+// Coppia di limiti (da revisione): globale per token (confine di sicurezza) + per
 // sessione (fairness). Una richiesta oltre-limite consuma comunque il budget
 // globale: anche lo spam rifiutato e' attivita' del principal.
 function createSenderLimiter(rateCfg = {}) {
@@ -189,7 +189,7 @@ function notifyRoutes({
         // R31-A3: lo status e' DERIVATO dai conteggi, non dichiarato a parte.
         // `emit` e' best-effort — push fallito → 0, `ui` conta i write SSE
         // riusciti — e il dispatcher propaga SOLO l'etichetta (i conteggi
-        // muoiono in forward(), rilievo R1/rc.14): per la cella mittente e'
+        // muoiono in forward(), rilievo da revisione): per la cella mittente e'
         // tutta l'informazione. Non puo' affermare una consegna che i conteggi
         // smentiscono: zero canali raggiunti → 'no-delivery'.
         const status = delivered.ui + delivered.push > 0 ? 'delivered' : 'no-delivery';
@@ -222,7 +222,7 @@ function notifyRoutes({
 
   // --- web-push --------------------------------------------------------------
   // GET lettura pura; in READONLY push.vapidPublicKey() NON genera chiavi e
-  // segnala 503 (e.status) se assenti — F3.
+  // segnala 503 (e.status) se assenti — da revisione.
   r.get('/push/vapid', (_req, res) => {
     try { res.json({ publicKey: push.vapidPublicKey() }); }
     catch (e) { res.status(e.status || 500).json({ error: String(e.message || e) }); }
@@ -232,7 +232,7 @@ function notifyRoutes({
     try {
       const sub = req.body && req.body.subscription;
       const out = await push.subscribe(sub);
-      // F7: cap sul numero di subscription -> 429 (quota), input invalido -> 400.
+      // da revisione: cap sul numero di subscription -> 429 (quota), input invalido -> 400.
       if (!out.ok) return res.status(out.reason === 'cap' ? 429 : 400).json({ error: out.error });
       res.json({ subscribed: true, count: out.count });
     } catch (e) { res.status(500).json({ error: String(e.message || e) }); }
@@ -247,8 +247,8 @@ function notifyRoutes({
   });
 
   // --- asks ------------------------------------------------------------------
-  // F3: gated READONLY (mutGate) — crea stato durevole (asks.json) e domande
-  // che lo stesso server vieterebbe di rispondere. F5: rate-limit creazione
+  // da revisione: gated READONLY (mutGate) — crea stato durevole (asks.json) e domande
+  // che lo stesso server vieterebbe di rispondere. da revisione: rate-limit creazione
   // (globale per token + per sessione) + cap duro dello store -> 429.
   r.post('/asks', mutGate, json, async (req, res) => {
     try {
@@ -294,7 +294,7 @@ function notifyRoutes({
   });
 
   // Dismiss (scarta domanda): NON cancella la riga, la marca `dismissed` (lo
-  // storico serve). Stesso mutGate degli altri mutanti (F3: scrittura durevole).
+  // storico serve). Stesso mutGate degli altri mutanti (da revisione: scrittura durevole).
   // Idempotente; 404 se id inesistente; 409 se answering (claim attivo: non si
   // scarta una risposta in corso). Emette il frame per le UI aperte come fa
   // POST /asks con emitRaw: la card sparisce senza aspettare il poll.
@@ -312,7 +312,7 @@ function notifyRoutes({
     } catch (e) { res.status(500).json({ error: String(e.message || e) }); }
   });
 
-  // Answer: READONLY floor (il paste e' una scrittura PTY). F2 (audit): il
+  // Answer: READONLY floor (il paste e' una scrittura PTY). da revisione: il
   // ciclo e' claim atomico (open -> answering, sincrono, PRIMA dell'await del
   // paste) -> paste -> commit su successo / release su fallimento. Una sola
   // richiesta concorrente vince; le altre vedono 409. Paste fallito -> 502 e