diff --git a/CLAUDE.md b/CLAUDE.md
index 75fff7d..39c377f 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -78,6 +78,8 @@ In sviluppo, `vite-plugin-websocket.js` incorpora il server WebSocket dentro il
 
 I test E2E girano in serie (`workers: 1`) per evitare race condition sullo stato WebSocket. Eseguire `npm run serve` prima di `npm run test:e2e`.
 
+La copertura statement/linee della suite Vitest è oltre il 99%. Per testare `startServer()` (`server.js`) o i rami platform-dependent di `getNetworkIPs()` (`server-utils.js`) senza effetti collaterali reali (scrittura su `.segnapunti/state.json`, dipendenza dalla piattaforma), si mocka il modulo con `vi.mock`/`vi.doMock` (vedi `tests/integration/startServer.test.js` e `tests/unit/server-utils-platform.test.js`) invece di eseguire il codice reale.
+
 ## Deploy
 
 Il progetto si distribuisce tramite Docker. L'immagine è pubblicata sul registry Gitea self-hosted (`santantonio.sytes.net`):
diff --git a/README.md b/README.md
index a770413..6b89a00 100644
--- a/README.md
+++ b/README.md
@@ -242,8 +242,12 @@ Lo stato viene salvato in `.segnapunti/state.json` anche in modalità dev.
 | `npm run test:e2e` | Playwright — Chromium, Firefox, Mobile Chrome |
 
 Le suite Vitest coprono la logica di gioco (`gameState`, inclusa `formInizio`),
-il protocollo e il routing del server, la persistenza, il client WebSocket
-(`wsMixin`), i componenti Vue e la generazione del referto.
+il protocollo e il routing del server (incluso l'avvio effettivo di
+`startServer`), la persistenza, il rilevamento di rete/piattaforma
+(`server-utils`, inclusi i rami WSL/PowerShell), il client WebSocket
+(`wsMixin`, connessione/riconnessione/cleanup), i componenti Vue e la
+generazione del referto (inclusi i suoi side-effect di stampa). La copertura
+statement complessiva è oltre il 99%.
 
 > I test E2E richiedono il server in esecuzione (`npm run serve`) e i browser Playwright installati:
 > ```bash
diff --git a/tests/README.md b/tests/README.md
index 2192baf..469a056 100644
--- a/tests/README.md
+++ b/tests/README.md
@@ -94,7 +94,9 @@ Esempi reali nel progetto:
 - time out (`startTimeout`/`stopTimeout`: squadra, video, timestamp)
 - generazione del referto (`buildRefertoHtml`)
 - persistenza stato su disco (`persist.js`, con `fs` mockato)
-- utility di rete (`server-utils.js`)
+- utility di rete (`server-utils.js`), incluso il rilevamento piattaforma
+  (WSL/PowerShell vs. `os.networkInterfaces()`, con `fs`/`child_process`/`os`
+  mockati per non dipendere dalla macchina che esegue i test)
 - elenco video spot (`spot-utils.js`, su cartella temporanea reale)
 
 Quando falliscono:
@@ -119,6 +121,8 @@ Esempi reali nel progetto:
 - autorizzazioni (solo controller puo inviare certe azioni)
 - timer server-side del time out (auto-`stopTimeout` dopo 30s, `startedAt` impostato dal server)
 - routing del server Express (`createApp`: rotte display/controller/asset, `/spot/list` e file statici `/spot/`)
+- rami di errore del WebSocket handler (`ws.send`/`ws.terminate` che lanciano, `applyAction` che fallisce a metà azione: lo stato precedente va ripristinato senza propagare l'eccezione)
+- avvio effettivo di `startServer` (`server.js`): ascolto HTTP, upgrade su `/ws`, rifiuto su altri percorsi, persistenza dopo un'azione — con `persist.js` mockato per non toccare mai `.segnapunti/state.json` reale
 
 Quando falliscono:
 - spesso c'e problema nel protocollo messaggi o nei controlli di ruolo
@@ -138,8 +142,9 @@ Esempi reali nel progetto:
 - dialog reset/config/cambi
 - modal time out del controller (scelta squadra/video, banner, countdown)
 - overlay time out del display (video, placeholder, countdown, dissolvenza)
-- bottone REFERTO nel dialog PARTITA FINITA
-- client WebSocket (`wsMixin`: connessione, riconnessione, `sendWs`, errori)
+- bottone REFERTO nel dialog PARTITA FINITA e generazione del referto stampabile (`generaReferto`: `window.open`, scrittura HTML, stampa)
+- client WebSocket (`wsMixin`: connessione, riconnessione con backoff, cleanup allo smontaggio, `sendWs`, errori)
+- layout esteso/landscape del controller (pannelli squadra, popup automatico SET VINTO con soglia decisiva)
 
 Quando falliscono:
 - spesso hai rotto template, computed, metodi o binding
@@ -190,8 +195,8 @@ Note importanti:
 Caso OK (verde):
 
 ```text
-Test Files  10 passed (10)
-Tests      212 passed (212)
+Test Files  15 passed (15)
+Tests      362 passed (362)
 ```
 
 Significa:
@@ -208,7 +213,7 @@ Caso KO (rosso):
 Caso OK:
 
 ```text
-75 passed
+81 passed
 ```
 
 Caso KO:
@@ -279,7 +284,23 @@ npm run test:e2e -- --update-snapshots
 npm run test:e2e
 ```
 
-## 10) Come aggiungere un nuovo test (consigli pratici)
+## 10) Copertura del codice
+
+Non c'è uno script `npm` dedicato, ma si può controllare la copertura in
+qualsiasi momento con:
+
+```bash
+npx vitest run tests/unit tests/integration tests/component --coverage
+```
+
+Il report a schermo mostra percentuale e righe scoperte per file. La suite
+attuale copre oltre il 99% di statement/linee; le poche righe rimaste
+scoperte sono documentate nei commit dei rispettivi test come codice morto,
+difensivo, oppure legato a HMR (`import.meta.hot`) o all'avvio diretto
+(`node server.js`) — casi non testabili in modo significativo senza side
+effect reali sull'ambiente.
+
+## 11) Come aggiungere un nuovo test (consigli pratici)
 
 - metti i test nel posto giusto:
   - `tests/unit` per logica pura