Attività del piano¶

Stato: ⬜ da fare · 🔄 in corso · ✅ fatto · ⛔ bloccato · ❌ annullato. Aggiornare stato, data e riferimento a ogni avanzamento.

Ogni attività indica: perché si fa, chi la esegue (ruolo), da cosa dipende, l'impatto sulla prod, i passi, quando è fatta e come si torna indietro.

Riepilogo rapido:

ID	Attività	Stato
T0.1	Backup logico di MySQL e Redis di prod	⬜
T0.2	Mettere in sicurezza ServerIT (modifica locale, regole d'uso)	⬜
T0.3	Pulizia dei port forward morti su pfSense	⬜
T0.4	Revisione delle regole VPN	⬜
T0.5	Inventario unico degli impianti	⬜
T0.6	Recupero della documentazione mancante	⬜
T0.7	Referente di Cloudflare per `bsqdev.uk`	⬜
T0.8	phpMyAdmin di prod	⬜
T0.9	Passaggio di consegne con Michele entro il 30/10	⬜ urgente
T1.1	Box di test collegati al dev	⬜
T1.2	Backup del database dev	⬜
T1.3	Coolify dev pronto per i test	⬜
T1.4	Piano di test definitivo	🔄 bozza in piano-test-dev.md
T1.5	Prova dell'aggiornamento remoto dei box	⬜
T2.1	Riportare in `stage` i comportamenti della 3.2.9	⬜ (analisi fatta il 29/10)
T2.2	OME per ambiente e segreto di produzione (M27)	🔄
T2.3	Release candidata e rilascio della linea `stage`	⬜
T2.4	Connessioni alle telecamere e live (MDM-037, 038, 039)	⬜
T2.5	Funzioni del box, anti-manomissione e API v1 (MDM-082, 083, 084)	⬜
T2.6	Import delle configurazioni e ponte di aggiornamento (MDM-080, 081)	⬜
T3.1	v3: `async/callback`	⬜
T3.2	v3: `receive_log`	⬜
T3.3	v3: redirect per il pannello	⬜
T3.4	Pannello: pulizia e compatibilità	⬜
T3.5	v3: shared subscription MQTT e sessione stabile	⬜
T3.6	v3: lock Redis per il listener delle scadenze	⬜
T3.7	v3: compose di produzione	⬜
T3.8	v3: test automatici e di compatibilità	⬜
T3.9	v3: build su ECR	⬜
T3.10	v3: verifiche residue (`KEYS *`, stato della linea `stage`, cluster, risposte per `api.bsq`)	⬜
T3.11	Migrazione dei dati v2 → v3	⬜
T3.12	Pagina live Protexia: non si porta nella v3 (D27)	Annullata (D27)
T3.13	Preparare il codice a un futuro cambio di dominio	⬜
T4.1–T4.10	qAlarm 2 pronto per la prod	⬜
T5.1–T5.4	Validazione in dev e GATE A	⬜
T6.1–T6.5	Infrastruttura di prod	⬜
T7.1–T7.4	qAlarm 2 pilota e GATE B	⬜
T8.1–T8.5	Cambio del midserver e GATE C	⬜
T9.1–T9.3	Aggiornamento dei box	⬜
T10.1–T10.8	Dismissioni e consolidamento	⬜

Fase 0 — Messa in sicurezza¶

T0.1 — Backup logico di MySQL e Redis di prod ⬜¶

Perché: M8, R7. Oggi l'unico backup è lo snapshot settimanale della VM.
Chi: Sviluppo + Sistemi.
Impatto sulla prod: basso (dump con --single-transaction, nessun blocco delle tabelle InnoDB).
Passi:
Su ServerIT, dump di q_alarm_mid (comando in comandi-verifica.md), compresso e con data nel nome.
Copia dello snapshot di Redis (BGSAVE, poi copia di dump.rdb dal volume).
Spostare i file fuori dalla VM (NAS in ufficio o S3 cifrato con accesso limitato). Non lasciarli in /tmp.
Ripristinare il dump su una istanza MySQL di dev e contare le righe delle tabelle principali.
Esportare anche la configurazione di pfSense (Diagnostics → Backup & Restore) e conservarla cifrata: contiene chiavi VPN.
Fatto quando: esiste un dump ripristinato con successo in dev, e la procedura è scritta nel runbook.
Rollback: non serve.

T0.2 — Mettere in sicurezza ServerIT ⬜¶

Perché: M3, M18. Un docker compose down svuota Redis; la modifica locale al compose si perde con un git pull.
Chi: Sviluppo.
Impatto sulla prod: nessuno (passi 1–2), basso (passo 3, opzionale e da approvare).
Passi:
Salvare la modifica locale: copia di docker-compose.yml e del backup del 27/10 in un posto noto, e annotarla nel repository (commit su un branch ops/serverit-prod-state senza segreti).
Diffondere a tutti le regole d'uso di prod.
(Opzionale, con approvazione) Attivare l'AOF su Redis a caldo (CONFIG SET appendonly yes): riduce la perdita di dati in caso di crash. Non sopravvive a una ricreazione del container: la soluzione definitiva è in T3.7.
Fatto quando: la configurazione reale di prod è salvata e le regole sono note al team.
Rollback: passo 3: CONFIG SET appendonly no.

T0.3 — Pulizia dei port forward morti su pfSense ⬜¶

Perché: M2. Inoltri verso 192.168.1.108 (1883, 6379, 8888) e 9090–9093 non portano a niente oggi, ma esporrebbero servizi se quegli indirizzi o porte venissero usati.
Chi: Sistemi (Michele).
Impatto sulla prod: nessuno, se si tolgono solo quelle regole.
Passi:
Backup della configurazione di pfSense.
Rimuovere i port forward 185.31.66.185:1883/6379/8888 → 192.168.1.108 e 185.31.66.185:9090–9093 → 170.10.0.108, con le regole WAN associate.
Verificare da rete esterna che pannello, API e video funzionino ancora.
Fatto quando: le regole non esistono più e i servizi rispondono.
Rollback: ripristino del backup della configurazione.

T0.4 — Revisione delle regole VPN ⬜¶

Perché: R3. Le regole lette il 27/10 permettono a ogni box di raggiungere tutto; gli AllowedIPs dei box (solo 172.16.16.1, .253, .254) limitano il tunnel ma non le porte di ServerIT.
Chi: Michele + Lorenzo. Solo analisi: le modifiche si fanno in T10.5.
Impatto sulla prod: nessuno.
Passi:
Leggere insieme le regole Floating, del gruppo WireGuard e delle interfacce WG_VPN e WG_STS_CAVA. In pfSense l'ordine è Floating → gruppo → interfaccia. Secondo Michele le regole dei box sono su WG_VPN: annotare in quale scheda sta l'allow any → any.
Prova pratica da un box (comandi in comandi-verifica.md): se il box raggiunge MySQL, phpMyAdmin, ewelink, pfSense o un altro box, R3 è confermato e resta aperto. La prova da un PC sulla VPN aziendale di Cava non vale, perché Cava ha regole diverse.
Tenere conto che i peer sono solo impianti dei clienti; i PC dei dipendenti arrivano dal tunnel di Cava.
Elencare il traffico necessario: box → midserver (5000, 1883), box → OME (9999 UDP su IP pubblico), Cava → box (RTSP 554/8554, stream nginx 10101–10105, 5005, 1996, 2000), Cava → LAN (SIP, ewelink, midserver), box → DNS/NTP se servono.
Scrivere la proposta di regole in pfsense-rete-vpn.md, separando box e Cava.
Fatto quando: l'esito della prova è annotato in rischi-e-problemi.md (R3) e la proposta è scritta e approvata da Michele.
Rollback: non serve.

T0.5 — Inventario unico degli impianti ⬜¶

Perché: R5, A11, M20. Le informazioni su ogni impianto sono sparse tra Redis, BSQ, pfSense, il Raspberry di Michele e FreePBX.
Chi: Michele + Lorenzo.
Impatto sulla prod: nessuno.
Passi:
Censimento del 28/10 fatto (risultati, script): 28 box MDM rispondono con versione, telecamere e MAC; da riconciliare con Redis (38) e chiarire i 5 box senza API 5005, i 13 GANZ irraggiungibili e l'IP duplicato.
Punto di partenza: l'export del database del Raspberry di Michele (raw/raspberry_db/ganzcortrol_controls.system.csv, 68 impianti con tipo, indirizzo VPN e relè Sonoff). Va completato con MAC e versione (da Redis, collegando per indirizzo VPN o nome), interno della tromba (FreePBX) e distinzione interni/società esterna.
Costruire una tabella: codice impianto, MAC, IP VPN, tipo di peer (box cliente o PC dipendente), sistema (MDM / vecchio / società esterna), versione del box, detector, numero di telecamere, relè Sonoff, interno tromba, stato.
Censimento del cluster master/slave (analisi del codice): oltre agli impianti candidati, elencare i siti multi-box vecchi già in produzione, i cui slave non hanno IP VPN e non compaiono nel censimento automatico. Prima indicazione: segnare gli impianti con molte telecamere che hanno (o avranno) bisogno di più box. Oggi nessun box MDM usa il cluster (esiste solo nella linea stage), ma serve sapere quali impianti lo richiederanno per pianificare la Fase 9. Il numero di telecamere di ogni box MDM si ricava dallo stato in Redis.
Conservarla in un luogo protetto: contiene dati dei clienti, quindi non va in questa documentazione né nei repository.
Segnare i box dismessi da rimuovere dal pannello in T9.3. Per i 3 box offline (uno dal 26/10, due da agosto) non si sa ancora se siano dismessi: resta un punto aperto.
Fatto quando: ogni peer VPN e ogni chiave Redis corrisponde a una riga.
Rollback: non serve.

T0.6 — Recupero della documentazione mancante ⬜¶

Perché: R5.
Chi: Michele, Mohammad.
Passi: raccogliere e aggiungere a fonti:
procedura WireGuard e documentazione FreePBX: ricevute il 30/10, in nuovo-peer-wireguard.md, preparazione-pc-ubuntu.md e freepbx-trombe.md;
guida del progetto televigilanza-mdm;
qualsiasi nota di Franco sul cluster master/slave e sul PR "componenti critici" (blocco dell'inserimento se un componente critico non funziona).
Fatto quando: i documenti sono nella cartella fonti e richiamati dalle pagine giuste.

T0.7 — Referente di Cloudflare per `bsqdev.uk` ⬜¶

Perché: R6. I nomi api, ome, panel di bsqdev.uk devono restare attivi a lungo.
Novità del 30/10: le credenziali di Cloudflare sono state condivise da Michele su Passbolt; bsqdev.uk è il dominio creato da Marco. Resta da nominare il responsabile.
Chi: Enrico / Emanuele.
Passi: identificare chi gestisce l'account; comunicargli per iscritto quali record vanno mantenuti e verso quali IP; chiedere un contatto per le emergenze (per esempio un certificato scaduto).
Fatto quando: il referente è noto e ha confermato.

T0.8 — phpMyAdmin di prod ⬜¶

Perché: M18. Interfaccia con accesso arbitrario a qualsiasi MySQL, aperta a tutta la VPN.
Chi: Sviluppo, con approvazione.
Impatto sulla prod: basso (nessun servizio dipende da phpMyAdmin).
Passi: capire chi l'ha cambiato il 27/10 e chi lo usa; se non serve in continuo, fermarlo (docker stop) e riavviarlo solo quando serve; in ogni caso togliere PMA_ARBITRARY=1 nel compose v3 di prod (T3.7).
Fatto quando: phpMyAdmin non è più raggiungibile in modo permanente da tutta la VPN.
Rollback: docker start qalarm_internal_new-phpmyadmin-1.

T0.9 — Passaggio di consegne con Michele entro il 30/10 ⬜ (urgente)¶

Perché: R5. Michele lascia l'azienda e sarà presente fino al 30/10/2026; rete, VPN, FreePBX, backup e il suo sistema dipendono da lui.
Chi: Lorenzo e Mattia, con Michele; Enrico organizza.
Passi:
Michele rivede la documentazione ricevuta e segnala errori e mancanze.
Risposte alle domande "Da chiedere a Michele" in domande-aperte.md.
Consegna dei documenti (WireGuard, FreePBX, sistema di Michele) e dell'elenco degli account amministrativi, nel gestore di password.
Sessione registrata in cui Michele mostra le operazioni ricorrenti: nuovo peer VPN, nuova tromba, riavvio di un impianto, controllo del Raspberry, ripristino di una VM.
Accordo su come contattarlo dopo il 30/10.
Fatto quando: le domande hanno una risposta scritta, i documenti sono in fonti e Lorenzo o Mattia sanno eseguire da soli le operazioni del passo 4.

Fase 1 — Ambiente di test completo¶

T1.1 — Box di test collegati al dev ⬜¶

Perché: nessuna modifica è mai stata provata end-to-end con box reali.
Chi: collega che fornisce le macchine + Lorenzo + Michele (peer VPN).
Dipende da: A1 (disponibilità delle macchine).
Passi:
Configurazione secondo P7 (decisioni.md): non solo l'ultima versione. Almeno un box 3.8 aggiornata (dopo T2.1–T2.3) e almeno uno 3.2.9, la versione del parco, per provare la compatibilità della v3 con i box di oggi e l'aggiornamento remoto 3.2.9 → 3.8. Se possibile un terzo 3.1.9.
Un peer WireGuard per ciascuno; configurazione che punta al midserver dev (172.16.16.252). Verificare quale porta espone Coolify dev per i box: la v3 ascolta su 5005, i box chiamano la 5000.
Almeno una telecamera (anche finta, un flusso RTSP di prova) per box, e se possibile una tromba e un relè di prova.
Attenzione: finché T2.2 non è fatta, il video dei box di test va all'OME di prod. È accettabile per i test, ma va saputo.
Fatto quando: i box compaiono nel pannello dev, online, e rispondono a un comando.
Avanzamento 28/10/2026: installata la versione stage effettivamente pubblicata (3.9.0-stage, commit d02dbaee) sul box di prova MDMTESTGANZ1, con HTTP/MQTT e video configurati sul dev. API locale e ricezione dello stato sul midserver dev verificate (HTTP 200). Restano da verificare la riga nel pannello e un comando dal dev, e da predisporre gli altri box di compatibilità. Installazione e rollback.

T1.2 — Backup del database dev ⬜¶

Perché: prima di toccare il dev serve un punto di ritorno.
Passi: dump del MySQL di Coolify dev e copia di Redis, come in T0.1.

T1.3 — Coolify dev pronto per i test ⬜¶

Dipende da: T3.7 per la parte di compose.
Passi: Redis con volume e AOF; tag fissi; healthcheck /health attivo in Coolify; risorsa "MDM-MidServer / dev branch" (ferma) eliminata o archiviata dopo conferma.
Fatto quando: il dev riproduce la configurazione prevista per la prod.
Avanzamento 28/10/2026: corretto il deploy del solo qAlarm dev, con progetto Compose stabile, repository persistente e conservazione del volume Redis (8 chiavi prima e dopo, backup RDB/AOF). API, Socket.IO e riconoscimento dei log verificati. Restano aperti gli altri requisiti di T1.3, inclusi health check e allineamento del midserver. Dettagli.

T1.4 — Piano di test definitivo 🔄¶

Passi: completare piano-test-dev.md con i casi della centrale (chiedere a un operatore quali azioni fa ogni notte).

T1.5 — Prova dell'aggiornamento remoto dei box ⬜¶

Perché: R12; prerequisito della Fase 9.
Chi: Lorenzo + tecnico.
Dipende da: T1.1.
Passi:
Sul box 3.1.9: aggiornare a 3.2.9 dal pannello (canale production). Misurare tempo e interruzione.
Provare a tornare indietro (3.2.9 → 3.1.9) e documentare come si fa.
Provare cosa succede se la connessione cade durante l'aggiornamento.
Il passaggio alla nuova versione non si prova con il canale stage (D22): lo copre T2.6.
Fatto quando: esiste una procedura scritta e provata in aggiornamento-box.md, con rollback.

Fase 2 — Codice dei box (`mdm_installation`, `mdm_frigate_wrapper`)¶

T2.1 — Riportare in `stage` i comportamenti della 3.2.9 🔄¶

Perché: D10. 42 commit solo su main; analisi del 29/10: quattro comportamenti da riscrivere (sincronizzazione telecamere leggera, database robusto, /status con cache, stato inserito/disinserito senza buchi), il resto è già presente o non serve (dettaglio).
Chi: Sviluppo. Ticket MDM-030.
Fatto quando: i quattro comportamenti sono in stage con i test.
Stato al 30/10: i quattro comportamenti sono committati su origin/stage con i test (fino a ebde226c). Restano /heartbeat (lavoro bloccante in una route async) e la conferma in laboratorio (MDM-081).

T2.2 — OME per ambiente e segreto di produzione (M27) 🔄¶

Perché: M15, M27. La linea stage legge già l'indirizzo di OME dal segreto AWS dell'ambiente; la prova live sul box stage di laboratorio è riuscita il 28/10. Nessun riporto nella 3.2.x (decisione del 28/10).
Resta: correggere il segreto mdm/installation/prod con gli indirizzi via VPN usati oggi dai box (MDM-031).

T2.3 — Release candidata e rilascio della linea `stage` ⬜¶

Dipende da: T2.1, T2.5 (API v1), T2.6.
Passi: candidata da stage con i tag di produzione; prove in laboratorio; unione in main solo al rilascio (inizio di T9.2), perché da quel momento ogni update dal pannello porta la nuova versione ai clienti (MDM-032).

T2.4 — Connessioni alle telecamere e live ⬜¶

Perché: R14. Il live non deve consumare le sessioni della telecamera usate dal rilevamento (connessioni-telecamere.md).
Ticket: MDM-037 (prove e censimento, DVR), MDM-038 (sorgente del live), MDM-039 (live sul box e transcodifica di OME).

T2.5 — Funzioni del box, anti-manomissione e API v1 ⬜¶

Perché: R15–R18, M31 (funzioni-del-box.md).
Ticket: MDM-083 (allarmi GANZ e API v1, prima della release), MDM-084 (funzioni da completare o togliere), MDM-082 (anti-manomissione con evento in qAlarm).

T2.6 — Import delle configurazioni e ponte di aggiornamento ⬜¶

Perché: l'update della 3.2.x scarica la nuova versione ma non sa avviarla, e la nuova versione non legge la configurazione vecchia (migrazione).
Ticket: MDM-080, MDM-081.

Fase 3 — Codice del midserver v3 (`mdm_mid_server`, branch da `refactor/v1`)¶

Branch di lavoro proposto: feat/v3-prod-readiness. Per ogni attività: test pytest (test_should_...), CHANGELOG.md.

T3.1 — `POST common/installation/async/callback/{token}` ⬜¶

Perché: tutti i box lo chiamano; manca nella v3 (parità).
Passi: studiare il comportamento in Flask (app/share/routes.py su dev), riprodurlo nella v3 con la stessa risposta, test con il payload reale di un box.
Fatto quando: un comando asincrono dal pannello dev a un box 3.2.9 completa correttamente.

T3.2 — `POST installation/receive_log/{mac}` ⬜¶

Passi: come T3.1, partendo da app/installation/installation_routes.py su dev; verificare dove finiscono i log (S3 it.bsq.mdm.logs).
Fatto quando: i log di un box 3.2.9 arrivano dove arrivano oggi.

T3.3 — Redirect per il pannello ⬜¶

Passi: POST /alarm_in/status, GET /installation/client_info, GET /installation/request/erros/{mac} (con il refuso), GET /installation/request/logs, POST /cameras/group_action. Verificare che anche i campi delle risposte coincidano con quelli che il pannello si aspetta.
Fatto quando: le 5 funzioni funzionano dal pannello dev.

T3.4 — Pannello: pulizia e compatibilità ⬜¶

Repository: mdm_web_panel.
Passi: rimuovere pagina /stream e chiamate /signaling/*; rimuovere request/call e connect/scp (0 chiamate in 30 giorni) dopo conferma; gestire l'assenza del PIN senza errori; correggere o nascondere il link Grafana (M12).
Fatto quando: nessuna chiamata del pannello verso la v3 risponde 404.

T3.5 — Shared subscription MQTT e sessione stabile ⬜¶

Perché: M6, M7. Con più istanze ogni evento verrebbe processato più volte; durante i riavvii gli eventi si perdono.
Passi: sottoscrivere $share/<gruppo>/... ai topic in ascolto (app/core/mqtt/client.py, startup_subscriptions); identificativo client univoco e stabile per istanza; valutare session expiry > 0 per non perdere messaggi durante i riavvii brevi. Verificare che Mosquitto supporti MQTT v5 con shared subscription.
Fatto quando: con 2 istanze attive ogni evento compare una sola volta nello stream.

T3.6 — Lock Redis per il listener delle scadenze ⬜¶

Perché: M6. Una sola istanza deve gestire le scadenze MAC_* (online/offline).
Passi: lock con lease (SET NX EX, rinnovo periodico, rilascio con compare-and-set sul proprietario) in app/core/redis/expiration_listener.py; le istanze non leader riprovano periodicamente.
Fatto quando: uccidendo l'istanza leader, un'altra prende il lock entro il TTL e una sola notifica di offline parte per ogni box.

T3.7 — Compose di produzione ⬜¶

Perché: M3, M9, M18, porta 5000.
Passi:
Redis con volume con nome e appendonly yes.
Tag fissi per redis, mosquitto, OME, exporter (niente latest).
Porta 5000 raggiungibile per i box (mappatura 5000 → 5005 o entrypoint del proxy).
Profilo di prod senza phpMyAdmin (o senza PMA_ARBITRARY).
Stessi volumi e credenziali di Mosquitto della v2 (i box non devono accorgersene).
Separare servizi con stato (MySQL, Redis, Mosquitto, OME) dal midserver, per poter aggiornare il midserver da solo.
Fatto quando: il compose gira in dev e regge un down/up senza perdere Redis.

T3.8 — Test automatici e di compatibilità ⬜¶

Passi: pytest per T3.1–T3.6; riuso dei test del branch e2e (scritti contro il Flask) come test di compatibilità contro la v3; test con payload reali registrati da un box 3.2.9 (senza dati dei clienti).
Fatto quando: i test girano in CI o con un comando documentato e sono verdi.

T3.9 — Build su ECR ⬜¶

Perché: M21, P5.
Passi: buildspecs/build.yml sul modello del pannello (REPOSITORY_NAME mid-server, versione da pyproject.toml); progetto CodeBuild e regola EventBridge su push (modifica AWS, da approvare); tag immutabili.
Fatto quando: un push produce mdm8670650/mid-server:<versione> e Coolify dev lo può usare.

T3.10 — Verifiche residue ⬜¶

Passi: sostituire KEYS * con SCAN se presente (M10); verificare la compatibilità con il formato di stato della linea stage e con il cluster; verificare che le 15 chiamate di api.bsq presenti nella v3 restituiscano gli stessi campi della v2 (test con le risposte reali, senza dati dei clienti).
Già chiuse il 27/10: chat/snapshot non si implementa (D17); il precedente requisito pagina del commit 6dd5e6b e ora annullato da D27 (T3.12).

T3.11 — Migrazione dei dati v2 → v3 ⬜¶

Perché: il registro dei box è in Redis, i backup in MySQL; la v3 può avere schemi o chiavi diversi.
Passi:
Confrontare chiavi Redis e tabelle MySQL tra v2 e v3.
Se diversi, scrivere uno script di migrazione idempotente con modalità di prova (dry-run).
Provarlo in dev su una copia dei dati di prod (dump di T0.1), senza dati dei clienti nei log.
Includere la rimozione dei box dismessi (da T0.5).
Fatto quando: lo script porta una copia dei dati di prod nella v3 dev e il pannello mostra gli stessi box.

T3.12 — Pagina live Protexia annullata (D27, 02/11/2026)¶

Rimossa dalla nuova app la pressione lunga verso la pagina HTML; rimane il player WebRTC interno con fullscreen. La pagina non va implementata nella v3 per la nuova app.
Modifiche locali: rollout e verifica live restano da completare. Le vecchie app possono ancora richiedere la pagina v2: nessuna rimozione sul server legacy.
Il live dev completo resta aperto: BSQ ha ancora URL prod fisso e inoltro JWT incompatibile con la v3. Modifiche BSQ annullate; futura rimozione del passaggio live (D28). Stato e fonti.

T3.13 — Preparare il codice a un futuro cambio di dominio ⬜¶

Perché: R6. I domini bsqdev.uk non sono sotto il nostro controllo e oggi non si può cambiarli, ma alcuni nomi sono scritti nel codice di software distribuito. L'obiettivo è che un futuro cambio di dominio sia solo una modifica di configurazione, senza rilasci urgenti.
Chi: Sviluppo (repository diversi; l'app e api.bsq vanno concordati con chi li mantiene).
Impatto sulla prod: nessuno: i valori di default restano quelli attuali.
Passi (inventario completo in domini-dns.md):
App Protexia: OME, TURN, STUN e midserver dai config/*.json, implementati localmente il 02/11; rimossa la pagina browser (D27). Verifica live e pubblicazione ancora da fare; preservare domini e servizio v2 per le app già distribuite.
api.bsq: modifiche a URL/token annullate (D28); baseline con dominio fisso preservata. Per gli stream si pianifica la rimozione del passaggio BSQ, senza aver ancora scelto o implementato la nuova API.
qAlarm FE: host OME da configurazione a runtime (già in T4.5).
Midserver v3: la pagina player Protexia non si implementa (D27); verificare i restanti riferimenti a domini nei template/codice.
Pannello MDM: i domini sono già in config/*.json, ma dentro l'immagine (M13): annotare che un cambio richiede una nuova build.
qAlarm BE: domini solo nei file app/config/*.yml e nei test: verificare che siano sovrascrivibili da variabili d'ambiente.
Aggiungere un controllo (script o test) che fallisce se compare bsqdev.uk fuori dai file di configurazione.
Fatto quando: git grep bsqdev.uk in ogni repository trova solo file di configurazione, documentazione e test, e l'app Protexia con host configurabili è pubblicata.

Fase 4 — qAlarm 2 pronto per la prod (`qAlarm2_be`, `qAlarm2_fe`)¶

ID	Attività	Problema	Fatto quando
T4.1 ⬜	Togliere la stampa del JWT (`app/middlewares/jwt_var.py:19`)	Q2	nessun token nei log
T4.2 ⬜	Endpoint di health; proteggere `/metrics`	Q4	Coolify usa l'health; `/metrics` non è pubblico
T4.3 ⬜	CORS e Socket.IO limitati ai domini configurati	Q5	richieste da un'origine non ammessa rifiutate
T4.4 ⬜	Build ECR per backend e worker	Q3	immagini `qalarm-be`/`qalarm-worker` su ECR con tag
T4.5 ⬜	Configurazione del frontend a runtime (API, socket, OME)	Q1, Q10	la stessa immagine funziona in dev e in prod
T4.6 ⬜	IP fissi di `prod.yml` da variabili d'ambiente	Q9	nessun IP nel codice
T4.7 ⬜	Worker: recupero dei pending (`XAUTOCLAIM`), nome consumer da hostname	Q6	un evento fallito viene ritentato
T4.8 ⬜	`Cache-Control: no-cache` su `index.html`	Q8	dopo un deploy i browser caricano la versione nuova
T4.9 ⬜	Barra sempre visibile con gli impianti offline (richiesta della centrale, 13/05)	—	visibile su ogni pagina, aggiornata in tempo reale
T4.10 ⬜	Test di accettazione locali (`qAlarm2_be/docs/local-acceptance-testing.md`)	—	scenari eseguiti contro il dev, risultati annotati

Fase 5 — Validazione in dev (GATE A)¶

T5.1 — Matrice di test end-to-end ⬜¶

Passi: eseguire piano-test-dev.md su v3 × box 3.2.9 / linea stage (/ 3.1.9) × pannello × qAlarm. Annotare ogni risultato.

T5.2 — Test di aggiornamento senza fermo ⬜¶

Passi: redeploy del midserver con un loop di richieste ogni 0,2 s (nessun 502/503); eventi MQTT inviati durante il redeploy (ognuno una sola volta nello stream); failover del lock; chiamata in attesa su wait durante il redeploy.

T5.3 — Prova di ripristino ⬜¶

Passi: ripristinare in dev il dump di prod (T0.1) e uno snapshot Redis; misurare il tempo; documentare.

T5.4 — GATE A ⬜¶

Passi: riunione con checklist-gate.md. Esito scritto in decisioni.md.

Fase 6 — Infrastruttura di prod¶

T6.1 — Dominio su Route 53 ⬜¶

Chi: Lorenzo (D16).
Dipende da: scelta del nome.
Passi: registrare il dominio; zona su Route 53; record per qAlarm (API, socket, frontend), pannello, API midserver, OME; TTL bassi all'inizio; accesso con utenze IAM personali.

T6.2 — VM "prod-apps" e Coolify di prod ⬜¶

Dipende da: decisione su P1 (A4). Non serve un IP pubblico nuovo: la VM usa 80/443 di 185.31.66.186, già nostro. Se si sceglie l'opzione (b) di P1 (qAlarm su ServerIT), questa attività e T6.3 non si fanno: qAlarm va su ServerIT con immagini ECR e un host in più su NPM.
Passi:
Confermare che la VM 400 è inutile, fare un ultimo backup e rimuoverla.
Creare la VM (4 vCPU, 8–16 GB, 80–100 GB) su vmbr1, IP 170.10.0.x libero, guest agent attivo.
Installare un Coolify separato da quello di dev; Traefik senza la porta 8080; amazon-ecr-credential-helper.
Inserire la VM nel backup Proxmox.
Fatto quando: Coolify prod risponde sul nuovo dominio con certificato valido.

T6.3 — pfSense per la nuova VM ⬜¶

Passi: port forward 185.31.66.186:80/443 → prod-apps; NAT in uscita; regola che permette solo a prod-apps di raggiungere 170.10.0.108:6379 (Redis del midserver, per il worker di qAlarm). Backup della configurazione prima, verifica che FreePBX e WireGuard su .186 funzionino dopo.
Rollback: ripristino della configurazione di pfSense.

T6.4 — Backup automatici ⬜¶

Passi: dump MySQL giornaliero (midserver e qAlarm) fuori dalla VM con conservazione definita; copia di Redis; export periodico della configurazione di pfSense; copia di tokens.json di ewelink; valutare backup Proxmox più frequenti per pfSense e ServerIT (disco aggiuntivo da Netsons). Prova di ripristino trimestrale.

T6.5 — Decisione su M1 prima di aprire la prod ⬜¶

Perché: D8 rimanda M1 "fino all'apertura della prod".
Passi: decidere se ruotare ora le chiavi AWS esposte (T10.6) o accettare il rischio per iscritto.

Fase 7 — qAlarm 2 in prod, pilota (GATE B)¶

T7.1 — Deploy di qAlarm 2 su Coolify prod ⬜¶

Passi: backend, worker e frontend da immagini ECR; database di qAlarm; collegamento a BSQ (RDS) e al Redis del midserver; health check e rolling update attivi.

T7.2 — Pilota con la centrale ⬜¶

Passi: 1–2 operatori usano qAlarm in parallelo a Telegram per alcune settimane; raccolta di problemi e richieste; nessuna procedura di emergenza dipende ancora da qAlarm.
Nota: gli allarmi arrivano a qAlarm solo dai box che passano dal midserver nuovo (stream eventi). Verificare quali impianti producono eventi nel flusso nuovo.

T7.3 — App Protexia con chat ⬜¶

Passi: pubblicare la versione dell'app con la chat verso qAlarm 2 e, nella stessa release, rendere configurabili gli host (T3.13).

T7.4 — GATE B ⬜¶

Passi: checklist-gate.md. Decidere se estendere qAlarm a tutta la centrale.

Fase 8 — Midserver v3 in prod (GATE C)¶

T8.1 — Preparazione del cambio ⬜¶

Dipende da: GATE A, T6.4; T9.1 (box allineati) solo se P4 viene confermata (domanda A25).
Passi: completare piano-cambio-midserver.md con i dettagli reali (immagini, comandi, tempi); concordare la finestra (A6); avvisare la centrale.

T8.2 — Prova generale in dev ⬜¶

Passi: eseguire l'intera procedura su Coolify dev partendo da una copia dei dati di prod, compreso il rollback. Cronometrare.

T8.3 — Esecuzione del cambio ⬜¶

Passi: piano-cambio-midserver.md. Decisione go/no-go con checklist-gate.md.

T8.4 — Osservazione ⬜¶

Passi: due settimane di osservazione con controlli manuali giornalieri; confronto giornaliero di box online, comandi falliti ed errori rispetto alla v2.

T8.5 — Dismissione della v2 ⬜¶

Passi: dopo l'osservazione, rimuovere i container v2; tenere l'immagine mid-server:2.2.0 e il backup per almeno 30 giorni.

Fase 9 — Aggiornamento dei box¶

T9.1 — 9a: tutti i box a 3.2.9 ⬜ (da confermare)¶

Perché: P4, non ancora decisa (domanda A25). Testare la v3 contro una sola versione, al costo di un giro di aggiornamenti in più sugli impianti.
Dipende da: T1.5 (procedura provata).
Passi: ondate: 1 box non critico → 3 box → gruppi di 5–10; tra un'ondata e l'altra almeno 24–48 ore di osservazione; mai di notte né nel fine settimana; un tecnico raggiungibile.
Fatto quando: i 38 box sono sulla stessa versione e tutti online.
Rollback: procedura di T1.5.

T9.2 — 9b: migrazione graduale alla nuova versione ⬜¶

Dipende da: Fase 8 conclusa, T2.3 (rilascio in main), T2.6.
Passi: stesse ondate di T9.1; per ogni ondata verificare video, comandi, stato, eventi verso qAlarm.
Prerequisiti: import delle configurazioni 3.2.x (MDM-080) e ponte di aggiornamento nella release unita in main, provato in laboratorio (MDM-081): l'update della 3.2.x da solo non basta; i box restano su main (D22). Vedi migrazione-box-alla-nuova-versione.md.

T9.3 — Pulizia dei box dismessi ⬜¶

Passi: rimuovere dal registro (chiavi Redis) i box dismessi individuati in T0.5, dopo conferma.

Fase 10 — Dismissioni e consolidamento¶

ID	Attività	Dipende da	Note
T10.1 ⬜	ewelink nel midserver: funzione nella v3, un solo proprietario dei token, aggiornamento del watchdog di Cava e dei client `relay_on.php`, poi spegnimento del PHP	Fase 8	ewelink-integration.md
T10.2 ⬜	Spegnere Telegram e la pagina comandi quando tutta la centrale usa qAlarm; portare il controllo online/offline e il watchdog Sonoff del sistema di Michele	GATE B, T10.1	coordinare con Michele
T10.3 ⬜	Migrazione degli impianti Windows/GANZ interni rimasti (4 previste entro fine anno secondo la call dell'11/08)	Fase 9	gli impianti della società esterna restano su GANZ
T10.4 ⬜	Eventuale cambio di dominio e dismissione di `bsqdev.uk`, quando sarà possibile (codice già preparato in T3.13)	T3.13, adozione dell'app aggiornata	domini-dns.md
T10.5 ⬜	Segmentazione della VPN secondo T0.4; accesso a Proxmox e pfSense solo da reti di amministrazione	T0.4, sistema vecchio considerato	rischio alto: una regola sbagliata scollega gli impianti; procedere per gradi con rollback
T10.6 ⬜	Segreti: rotazione delle chiavi AWS esposte (M1), installer con credenziali minime e temporanee (M16), credenziali MQTT e del server diverse per box (M14)	T6.5	richiede aggiornamento dei box
T10.7 ⬜	Portare ServerIT sotto Coolify prod (server remoto) e sostituire NPM con Traefik, mantenendo i nomi `bsqdev.uk`	Fase 8	rolling update reale del midserver
T10.8 ⬜	Nuovo nome per "MDM"	—	decisione aziendale