Spegnere l'applicazione WordPress Storm Solution e fare di Storm Support l'unica fonte di verità per la gestione dei sinistri grandine. Non è una copia uno a uno: per ogni funzione ci si chiede cosa serve davvero al business, prima di guardare come lo fa WordPress.
Quadro al 12 novembre 2026, ricavato dalla cartella migrazione (inventario, analisi DDD, modello target, roadmap, piani F1–F2).
Oggi WordPress è il sistema master di tutto: pratiche, appuntamenti, tecnici, sostitutive, ricambi, documenti, fatture. La logica è sparsa tra tema, plugin e circa cento snippet scritti in produzione, senza confini riconoscibili. Storm Support è nato accanto e fa già molte cose meglio (capacità degli hub, pianificazione, conferme, comunicazioni con l'assicurato, Fast Pass), ma quando scrive passa da WP e aspetta che il webhook gli restituisca il dato.
Il volume è molto stagionale: 20–30 pratiche al mese d'inverno, tra 1.500 e 2.800 nei picchi estivi. Le pratiche precedenti al 2026 sono già state tolte da WP e stanno nei dump del database.
flowchart LR OP[Operatori] --> WP[(WordPress
master di tutto)] OP --> SS[Storm Support] SS -->|REST| WP WP -->|webhook| SS IP[inspecta-pro
in collaudo] -.-|nessuna integrazione| SS
Support è un downstream di WP. inspecta-pro, l'app per periti e hub, ha un proprio modello completo di pratiche, appuntamenti e anagrafiche e non parla con nessuno.
flowchart LR OP[Operatori · Expert ·
Amministrazione · Admin] --> SS[(Storm Support
fonte unica)] EST[Periti · Hub · Tecnici] --> IP[inspecta-pro
app di campo] IP -->|API v1 · chiave di servizio| SS SS -->|eventi| IP WP[WordPress] -.-x|spento| SS
Support scrive tutto. inspecta-pro diventa un'app di campo senza dati master, che legge e scrive su Support via API. WordPress viene archiviato e spento.
L'analisi DDD divide il lavoro di Storm in 14 contesti, tutti dentro Support come moduli separati, più il Campo come app esterna. Il peso del progetto sta nei tre contesti core, che sono anche quelli più fragili in WordPress.
| Tipo | Contesti | Come si investe |
|---|---|---|
| Core | Pratiche (ciclo di vita del sinistro) · Pianificazione (capacità, appuntamenti, plancia) · Valutazione danno (perizia, preventivo, autorizzazione, consuntivo) | Modello ricco, regole come comandi e test, operatori al tavolo, nessuna scorciatoia CRUD |
| Supporting | Acquisizione incarichi · Rete · Logistica veicoli · Ricambi · Documentale · Amministrazione · Relazione con l'assicurato · Mandanti e canali · Campo (inspecta-pro) | Modello sufficiente, anche semplice, purché con confini netti |
| Generic | Identità e accessi · Reporting | Componenti standard: ruoli e permessi, proiezioni sugli eventi |
Si sposta la proprietà del dato un dominio per volta. Per ognuno si ripetono gli stessi quattro passi, e ogni passo si può annullare finché la sync inversa è attiva.
Entità del target e comandi locali in Support.
Import da WP ripetibile e idempotente, con report di riconciliazione.
Support diventa master. In WP si spengono le schermate che scrivono; una sync inversa tiene aggiornato WP per chi lo legge ancora.
Si disattiva la logica WP residua, poi la sync inversa quando nessuno la legge più.
Solo disattivazioni di snippet, interfacce del tema e configurazione dei plugin. Nessuna correzione né logica nuova: i bug di WP si risolvono spostando la funzione in Support.
wp/v2/<cpt> con i campi ACF, così gli hook e le tabelle custom continuano a funzionare. Niente rotte custom, niente SQL diretto.
Le inversioni pesanti si fanno tra novembre e marzo; nessun cutover tra maggio e settembre. Obiettivo dell'inverno 2026/27: agenda invertita sicuramente, pratica se possibile.
Le fasi sono ordinate per dipendenza e priorità, non per data. Le dimensioni (S, M, L, XL) indicano lo sforzo relativo. F2 è il fast track: tecnici, sostitutive e agenda vengono prima perché spengono la gestione appuntamenti in WP, la parte che gli operatori usano ogni giorno.
Rotazione delle credenziali, controllo della basic auth del webhook in Support, aree sensibili riservate agli admin, Code Snippets congelato. Indipendente dal resto.
Confini tra contesti verificati in CI, eventi di dominio affidabili, ruoli e permessi con import degli utenti WP, sync inversa generica verso WP, comandi locali dell'agenda.
Anagrafica tecnici e loro agenda, flotta sostitutive con contratti e capienza, appuntamento master in Support, plancia tecnici, trasporto bisarca, poi il passaggio con spegnimento delle schermate WP. Uscita: nessun appuntamento creato o modificato in WP per due settimane.
Compagnie con regole e tariffari, agenzie, hub, studi peritali, fornitori.
La fase più importante. Veicolo → Sinistro → Pratica, macchina a stati con blocchi separati, code di lavoro, migrazione delle 10.306 pratiche. Uscita: un ciclo completo lavorato solo in Support su un campione reale.
Circa 156.000 file verso lo storage di Support con verifica degli hash, documenti tipizzati, moduli della compagnia e Scheda 11 generati lato server, perizia strutturata.
inspecta-pro diventa client di Support: contratto OpenAPI, chiave di servizio, flussi in uscita (agenda, incarichi) e in ingresso (conferme, perizie, foto). Ogni flusso esterno ha sempre un'alternativa nel back-office.
Ricambio con stati, magazzino, resi e trasferimenti; trasporti e movimentazioni se non già portati.
Righe economiche, proforma e richieste di fattura generate da Support, fatture passive e attive, incassi, migrazione di 21.546 proforma e 15.187 fatture.
Report di avanzamento sulle transizioni, KPI degli Expert, analisi tecnici e acquisti.
Pratiche precedenti al 2026 dai dump del DB WP, importate in sola lettura e separate dal flusso vivo.
Due-quattro settimane senza scritture né webhook da WP, rimozione del codice di integrazione da Support, WP in sola lettura e poi archivio freddo.
| Parte | Stato |
|---|---|
| Inventario WP, Support oggi, inspecta-pro | Bozze complete, aggiornate all'11 novembre; da validare |
| Mappa capability, modello target, roadmap | Proposte da discutere; decise D1–D4 e D6, aperta D5 |
| Analisi DDD | Completa: 14 contesti, context map attuale, target e di transizione, linguaggio ubiquo, 20 dubbi con raccomandazione |
| Piani F1 e F2 | Undici piani scritti e rivisti dopo il rebase su main; F2-05 (plancia) da ridiscutere |
F1-01Convenzioni, confini, eventiIN EPICF1-02Accessi, ruoli, utenti WPIN EPICF1-03Sync inversa verso WPIN EPICF1-04Comandi dell'agendaIN CORSOF2-01 … F2-04Tecnici, agenda tecnico, flotta, appuntamento masterPIANIFICATIF2-05 … F2-07Plancia, bisarca, passaggio e spegnimento WPPIANIFICATIL'epic epic/migrazione-F1 è riallineato su main dal 12 novembre: 5371 test verdi, controlli dei confini puliti. Non è ancora in produzione.
| Rischio | Impatto | Come si mitiga |
|---|---|---|
| La sync inversa non copre un lettore WP e qualcosa si rompe in silenzio (solleciti, PDF, ricambi) | Alto | Elenco dei 23 snippet e circa 20 file del tema che leggono gli appuntamenti; scrittura via ACF; riconciliazione |
| Gli operatori trovano plancia e calendario di Support meno efficienti di WP | Alto | Validazione con 2–3 operatori prima di spegnere le schermate WP |
| Inversione durante l'alta stagione | Alto | F2 entro marzo 2027; F4 solo in bassa stagione |
| Loop o conflitti nella sync bidirezionale | Alto | Proprietà per campo, filtro anti-eco, cruscotto delle proiezioni |
| Logica nascosta negli snippet non censita | Medio | Code Snippets congelato; inventario rivisto prima di ogni spegnimento |
| Il modello di inspecta-pro non combacia con quello di Support | Alto | Analisi fatta prima del contratto API; mappa degli id; fallback nel back-office |
Cosa cambia nel codice con F1 e quali regole rispettare nelle nuove funzionalità: Storm Support dopo F1.