2 Funzionamento

⚙️ Capitolo 2: Architettura e Funzionamento (Sotto il cofano)

Il funzionamento del motore Panzer v7 si basa su tre pilastri architetturali rigidi progettati per la massima resilienza.

---

🌐 1. Scope Globale (sw.js nella Root)

Il file del Service Worker (sw.js) è posizionato chirurgicamente nella cartella radice (root) del dominio. Questo permette al software di intercettare ogni singola richiesta di rete dell'intera applicazione, agendo come un proxy locale installato nel browser dell'utente.

---

⚡ 2. Strategia di Fetch: Network-First con Profilazione Dinamica e Autorigenerazione

Il motore adotta un algoritmo avanzato di tolleranza ai guasti di rete per scongiurare il blocco dell'interfaccia in caso di connettività degradata (fenomeno della "Lie-Fi"):

1. Profilazione Dinamica della Rete (getNetworkProfile): Il sistema non si limita a verificare lo stato online/offline. Calcola in tempo reale un punteggio di efficienza basato sui parametri navigator.connection (downlink e RTT), adattando dinamicamente i timeout e la parallelizzazione dei download secondo la tabella sottostante:

Profilo Rete	Limite Download Simultanei	Timeout di Connessione	Comportamento Bunker
Ultrafast	12 file	15 secondi	Sincronizzazione aggressiva
Fast	8 file	20 secondi	Sincronizzazione standard
Medium	4 file	45 secondi	Sincronizzazione standard
Low	2 file	90 secondi	Controllo HEAD esteso
Verylow	1 file	120 secondi	Blocco preventivo del Sync

2. Network-First con Race Condition: Ogni richiesta dinamica intercetta la rete per garantire la massima freschezza del dato, applicando i secondi di timeout definiti dal profilo di rete attivo.
3. Cache Fallback & Hot Update: In caso di timeout, il Service Worker rilascia immediatamente la risorsa locale memorizzata nel Bunker. Se invece la rete risponde in tempo, il sistema aggiorna la cache in background (Hot Update).
4. Radar degli Aggiornamenti (ver_site): Il sistema monitora le variazioni dell'HTML principale. Se viene intercettato un Major Update, il Service Worker esegue autonomamente una tabula rasa delle vecchie cache per prevenire conflitti logici o disallineamenti tra i moduli core.

---

🔍 3. Validazione Strict via SW Forensics (isValidBlob)

Per evitare attacchi informatici (come il Cache Poisoning), pagine di login di hotspot Wi-Fi (captive portal) o file corrotti, ogni risorsa subisce una validazione rigorosa prima dell'ingresso nello storage:

1. Controllo Dimensionale: Verifica della dimensione minima del file tramite la mappa delle specifiche interne (CONFIG.minSizeMap).
2. Firma Magica (DNA del File): Analisi dei primi byte binari (i Magic Numbers) per verificare la reale identità e integrità del dato prima di elaborarlo, rifiutando file con estensioni falsificate.

---

📦 Gestione dei Magazzini e della Memoria

Il sistema opera una separazione netta dello storage logico, tracciato nei log di console con marcatori specifici:

• 📦🛡 (Bunker): Area protetta e isolata per gli asset Core + Manifest asset, di sistema.
• 📦🔓 (Magazzino): Area sussidiaria per le risorse utente dinamiche e volatili.

---

🧬 Routine di Factory Reset, Messaggistica Frontend e Re-Installazione Totale

Il motore implementa una logica di tolleranza ai guasti di tipo distruttivo-rigenerativo sincronizzata con l'interfaccia utente:

1. Tabula Rasa Immediata: Se il database del Vault o le chiavi logiche in IndexedDB risultano corrotti, il Service Worker cancella istantaneamente tutte le istanze di cache attive (Bunker e Magazzino).
2. Notifica di Emergenza via postMessage: Il Service Worker invia immediatamente un segnale di notifica broadcast a tutte le finestre aperte del frontend.
3. Forzatura del Refresh e Re-Installazione: Il frontend, intercettato il comando, forza un ricaricamento immediato della pagina. Qualora la comunicazione diretta dovesse fallire, l'azione si concretizza autonomamente alla riapertura successiva dell'applicazione: il browser si comporterà come se si trattasse di una prima installazione di zecca, riscaricando dal server tutti i file core integri ed eliminando alla radice ogni traccia di corruzione.

In caso di saturazione del dispositivo client (QuotaExceededError), si attiva la routine d'emergenza 🚨 SW: Storage Pieno! Emergency Clean... che avvia la pulizia automatica del Magazzino volatile per salvaguardare i file vitali custoditi nel Bunker. In assenza dei prerequisiti minimi di sicurezza o delle chiavi logiche in IndexedDB, il sistema si isola in modalità protetta (VAULT_LOCKED_NO_KEY).

---

🛠️ Diagramma di Flusso delle Richieste

[ UTENTE / BROWSER ]
       │
       ▼ (Ogni richiesta: immagini, HTML, JS)
┌─────────────────────────────────────────┐
│     SERVICE WORKER (`sw.js` nella Root)  │ <─── Filtro/Proxy Globale
└─────────────────────────────────────────┘
       │
       ├─► [ getNetworkProfile ] ──► Calcola Profilo Rete (Timeout Dinamici)
       │
       ├─► [ C'È RETE? ] ──► SÌ ──► Valida Blob (`isValidBlob`) ──► Aggiorna Cache
       │
       └─► [ NO RETE / TIMEOUT! ]  ──► NO (Bunker Mode)
                                          │
                                          ▼
                              ┌───────────────────────┐
                              │     CACHE LOCALE                     │
                              │ 📦🛡 Bunker (Crypted)                │
                              │ 📦🔓 Magazzino (Not_crypted)         │
                              └───────────────────────┘
                                          │
                                          ▼
                               Rilascia i file alla PWA

↩ Torna alla Home