Dal file Excel anonimizzato all’analisi HSE per il management. Fase 2: creiamo una dashboard HSE interattiva e autonoma con il vibe coding

L’IA aiuta a costruire l’involucro software su un modello Excel anonimizzato, mentre il vero database di lavoro viene caricato nell’HTML finito già in locale, sul computer dell’utente.

Introduzione

Nella prima pubblicazione ho mostrato come abbiamo risolto la questione della preparazione sicura dei dati: abbiamo creato uno strumento locale di mascheramento e imparato a ottenere un modello Excel anonimizzato che conserva la struttura del database di lavoro senza trasmettere dati personali reali a un ambiente di IA esterno.

La domanda successiva arriva quasi subito: che cosa farne, poi, di questo modello?

Il nostro obiettivo non era semplicemente costruire qualche grafico. Serviva uno strumento analitico funzionante, utilizzabile nella preparazione delle comunicazioni a cascata e dei comitati per la sicurezza: cambiare la selezione, scendere da un indicatore generale all’unità, all’area e al singolo record, vedere i colli di bottiglia e preparare rapidamente il materiale per il confronto con i dirigenti.

Restava valida la condizione principale della prima fase: durante lo sviluppo esterno il database di lavoro reale dell’azienda non viene trasmesso all’IA.

Perché è servita una dashboard propria

I nostri dati di partenza vengono generati in forma digitale da tempo. I dialoghi comportamentali di sicurezza (BSD) e il controllo dei rischi critici (CRC) vengono svolti da dirigenti e specialisti tramite l’app aziendale CoLab. Il problema, quindi, non era la mancanza di dati, ma il passo successivo: come trasformare rapidamente una grande massa di record in analisi gestionale comprensibile.

Il sistema aziendale consente di effettuare l’osservazione, compilare i campi e generare un export. Un’elaborazione analitica più profonda richiede però uno sviluppo IT a parte. Con un numero limitato di specialisti, tempi e budget, richieste di questo tipo possono attendere a lungo.

Le prime dashboard online basate su Superset coprono i compiti quantitativi di base. Per il lavoro pratico non bastano. Se un dirigente vede che sono stati effettuati 500 controlli o rilevate 70 deviazioni, la domanda successiva è sempre la stessa: dove esattamente è successo, perché e quali record concreti ci stanno dietro.

Per questo consideriamo la dashboard HTML autonoma non come un sostituto dei sistemi IT aziendali, ma come un rapido strumento intermedio. Permette di verificare l’analisi nella pratica in poco tempo, di capire quali indicatori servono davvero e dove occorre scendere fino ai dati primari — e solo dopo di formulare una specifica tecnica più precisa per la realizzazione industriale.

Passo 1. Prima capire i dati, non scrivere il programma

Uno degli errori più comuni lavorando con l’IA è chiedere subito: «Fammi una dashboard». Un’immagine gradevole si ottiene in fretta, ma non è affatto detto che poi sia utilizzabile.

Per questo la nostra prima richiesta all’IA è stata diversa. Caricavamo il modello Excel anonimizzato e chiedevamo di non programmare ancora nulla, ma di analizzare la struttura del file: quali fogli, colonne e tipi di dati contiene, quali campi sono collegati tra loro, che cosa si può usare nei filtri, quali indicatori si possono calcolare e dove la struttura di origine può contenere errori.

In questo modo l’IA interviene prima come analista dei dati, non come programmatore.

Per i dialoghi comportamentali di sicurezza, ad esempio, contano la data, l’azienda, il reparto, l’area, l’osservatore, il lavoratore, il tipo di comportamento, il processo, la descrizione e l’esito. Al posto del cognome reale l’IA può vedere «Dipendente_00001». Per costruire la logica della dashboard il cognome reale non le serve.

Prompt 1 — analisi della struttura del database anonimizzato: vedi l’appendice in fondo all’articolo.

Dialoghi comportamentali di sicurezza: dal numero complessivo al singolo record

La fase successiva consiste nel definire non un insieme di belle visualizzazioni, ma le domande gestionali a cui la dashboard deve rispondere.

Per i dialoghi comportamentali ci interessa vedere la dinamica, la struttura dei comportamenti rilevati, le unità, i processi, la ricorrenza delle deviazioni, il lavoro degli osservatori e la possibilità di passare dal numero complessivo al singolo record.

La logica si costruisce quindi dall’alto verso il basso: azienda → reparto → area → tipo di comportamento → processo → singolo record. Il clic su una barra o su un settore del grafico cambia la selezione e mostra esattamente i record che hanno formato l’indicatore.

Si aggiungono inoltre la ricerca per lavoratore o identificativo anonimizzato, lo storico delle deviazioni rilevate, la classifica delle unità e di chi conduce i BSD, nonché l’export della selezione corrente in Excel.

Qui applico una regola semplice: se dopo aver guardato un grafico non è chiaro quale decisione gestionale aiuti a prendere, con ogni probabilità quel grafico nella dashboard non serve.

Prompt 2 e Prompt 5 — struttura della dashboard HSE e dettaglio interattivo: vedi l’appendice in fondo all’articolo.

L’aggiunta del foglio presenze: come vedere la frequenza raccomandata stabilita dei BSD

Poi siamo andati un passo oltre. Per risparmiare tempo e non creare uno strumento separato, la stessa dashboard è stata integrata con il foglio presenze.

Per lo sviluppo è stato usato dapprima un modello anonimizzato del foglio presenze, poi — già in locale — quello reale. Ciò ha permesso di vedere non solo il volume dei BSD svolti, ma anche il rispetto della frequenza raccomandata stabilita.

In sostanza confrontavamo il numero di turni effettivamente lavorati con il numero di dialoghi di sicurezza effettivamente svolti. È così diventato visibile dove la frequenza richiesta viene rispettata e dove si accumula un ritardo.

Questo approccio è particolarmente utile ai capi reparto e ai capi area: la dashboard mostra non il volume complessivo di lavoro, ma il reale rispetto del requisito, con discesa fino all’unità, alla professione e al singolo lavoratore.

Questa evoluzione non ha richiesto un nuovo principio. Abbiamo semplicemente sviluppato la logica già creata e collegato un ulteriore insieme di dati.

Prompt 6 — analisi dei BSD tenendo conto dei turni effettivamente lavorati: vedi l’appendice in fondo all’articolo.

CRC: lo stesso approccio, ma per il controllo dei rischi critici

La stessa logica si applica al CRC. Dall’export di origine si può vedere quanti CRC sono stati effettuati e quanti di essi contenevano deviazioni. Ma il numero grezzo di per sé non risponde alla domanda principale: quanto viene realmente rispettato il requisito in ogni turno.

A tal fine nella dashboard vengono caricati in locale i dati CRC e il foglio presenze reale dello stesso periodo. Dopo il confronto si vede chi era effettivamente in turno, quanti CRC avrebbe dovuto svolgere e quanti ne ha svolti davvero.

In uscita otteniamo non solo il numero, ma anche la percentuale di adempimento, il deficit, l’elenco di chi non ha adempiuto e — in presenza di un database esteso — anche il collegamento ad area, reparto, processo e cause delle deviazioni.

Tutti i grafici restano cliccabili: dall’indicatore generale si può scendere più in profondità — all’unità, poi all’area, quindi alla professione e infine alla scheda di un lavoratore specifico o di un record specifico.

In questo articolo non riporto screenshot dei CRC per non appesantire il materiale. Tecnicamente si usa lo stesso principio dei BSD.

Prompt 7 — CRC e foglio presenze reale: calcolo dell’adempimento e discesa fino al lavoratore: vedi l’appendice in fondo all’articolo.

Passo 2. Il primo prototipo e i miglioramenti successivi

Una volta chiare la struttura dei dati e la logica dell’analisi, si può passare direttamente al vibe coding.

Il compito si formula ormai in modo abbastanza concreto: creare un unico file HTML autonomo che si apra in un normale browser, contenga KPI, filtri, grafici interattivi e una tabella dei record di origine e funzioni senza installare software aggiuntivo.

In questa fase all’interno del programma si usano ancora soltanto dati anonimizzati.

La prima versione non è quasi mai definitiva. Scegli un’azienda — e l’elenco dei reparti resta generico. Clicchi su un grafico — e non c’è la discesa fino al record. Aggiungi una nuova funzione — e una delle visualizzazioni smette di funzionare correttamente. È una parte normale dello sviluppo.

Invece di riscrivere l’intera applicazione, il compito viene posto in modo puntuale: «Rendi i filtri dipendenti», «Aggiungi il dettaglio al clic», «Correggi solo il grafico n. 6, non cambiare il resto della logica».

È proprio qui che il vibe coding è particolarmente utile a uno specialista che non è programmatore. Bisogna spiegare con precisione non come scrivere una funzione, ma come il programma deve comportarsi per l’utente.

Prompt 3, Prompt 5 e Prompt 8 — creazione del primo HTML, dettaglio e correzione dei difetti: vedi l’appendice in fondo all’articolo.

Passo 3. Togliamo il modello e carichiamo i dati reali in locale

Quando l’interfaccia e la logica sono state collaudate sul modello anonimizzato, i dati dimostrativi vengono rimossi dalla versione finale. L’HTML resta un involucro software.

Vi si aggiunge un pulsante di caricamento Excel. L’utente apre l’HTML finito sul computer aziendale, sceglie il database di lavoro aggiornato e il browser legge il file e calcola gli indicatori all’interno della sessione locale.

Lo schema finale è quindi semplice: l’HTML finito e il file Excel di lavoro si trovano sullo stesso computer; i dati di lavoro vengono caricati nel programma in locale e non vengono più trasmessi all’ambiente di IA esterno.

Nello screenshot pubblicato i cognomi reali sono coperti con ritocco. È importante: l’articolo deve mostrare il principio di funzionamento, non divulgare dati personali.

Prompt 4 — caricamento locale del database Excel di lavoro: vedi l’appendice in fondo all’articolo.

Caricamento, aggiunta, azzeramento e copia offline

Alle funzioni per l’utente è stata dedicata un’attenzione specifica. In pratica è importante non solo aprire la dashboard, ma anche gestirne rapidamente lo stato.

Sono state quindi aggiunte azioni separate: caricare una nuova tabella, cancellare completamente i dati, salvare una copia offline e azzerare i filtri senza cancellare il database. Sono scenari diversi e devono essere chiari all’utente al primo sguardo.

Inoltre ho registrato un breve video dimostrativo che mostra come funziona la dashboard sul modello anonimizzato, come si esegue un azzeramento completo e come vengono poi caricati i dati reali. Un’appendice video di questo tipo risolve i dubbi più in fretta di qualsiasi descrizione scritta.

Appendice video 1. Registrazione dello schermo: dal modello al database di lavoro — il video si trova in fondo all’articolo.

Dall’analisi al confronto gestionale

Il valore principale della dashboard non emerge sullo schermo, ma in riunione.

Le viste ottenute vengono usate nella preparazione delle comunicazioni a cascata e dei comitati per la salute e la sicurezza sul lavoro: dal livello delle unità fino al comitato centrale dell’azienda, che si riunisce ogni mese.

A livello di area si vedono i record concreti e i lavoratori. A livello di reparto — i problemi ricorrenti. Più in alto — il confronto tra unità e le zone sistemiche che richiedono l’attenzione dei dirigenti.

Per questo al comitato non arriva più solo la frase «adempimento: 82 %», ma un quadro molto più concreto: quali aree generano il ritardo, in quali turni il requisito non viene rispettato, quali tipi di deviazione si ripetono e quali record vanno esaminati con il responsabile.

La dashboard mostra dove cercare. La causa e la decisione gestionale restano compito delle persone.

Strumento temporaneo o futuro sistema industriale

Per noi la dashboard HTML autonoma non è un obiettivo finale e non compete con l’architettura IT aziendale.

Il suo compito è percorrere rapidamente la strada da un’idea di produzione a un prototipo analitico funzionante. Mentre si sviluppa la soluzione industriale, le unità possono già usare lo strumento per l’analisi e gli specialisti ricevono un riscontro pratico su quali indicatori servano davvero.

Se il prototipo ha confermato la propria utilità, la sua logica è molto più semplice da trasferire agli sviluppatori IT per la successiva realizzazione in JavaScript, in Superset o in un altro ambiente aziendale con integrazione automatica dei dati.

In altre parole, il vibe coding non sostituisce l’IT. Elimina parte dell’incertezza già prima dell’inizio del grande sviluppo: si capisce in anticipo quali filtri servono, dove deve funzionare la discesa, quali dati collegare e quale risultato gestionale deve ottenere l’utente.

Che cosa ne è uscito

Il risultato è che il modello Excel anonimizzato diventa un ponte tecnico tra il database di lavoro reale e l’IA. L’IA vede la struttura dei dati, aiuta a sviluppare logica e interfaccia, scrive e perfeziona il codice. Il database reale compare nello strumento solo quando l’HTML finito si trova già sul computer dell’utente.

Per uno specialista della sicurezza questo accorcia sensibilmente il percorso dall’idea al prototipo funzionante.

Il vantaggio principale non è che l’IA sappia disegnare grafici. L’essenziale è poter trasformare molto più rapidamente una questione di produzione in uno strumento analitico, vedere il collo di bottiglia e indirizzare l’attenzione del dirigente là dove serve davvero un’azione.

Nella prossima pubblicazione voglio passare dall’analisi dei dati a un’altra direzione: mostrare come l’IA, da semplice assistente, sia diventata gradualmente un «secondo esperto» che valuta la qualità dei briefing di sicurezza e dei dialoghi comportamentali secondo più criteri indipendenti.

Prompt pronti per creare una dashboard HSE autonoma su BSD e CRC

Regola pratica: all’ambiente di IA esterno viene trasmesso solo un modello anonimizzato verificato. I file Excel di lavoro reali, i fogli presenze e i dati personali vengono collegati dopo, in locale, all’interno dell’involucro HTML finito.

Come i prompt si collegano all’articolo

Prompt 1. Analisi della struttura del file Excel anonimizzato

Sto caricando un modello Excel anonimizzato di un database HSE di lavoro.

Per ora non programmare nulla.

Analizza:
1. i fogli del file;
2. le intestazioni delle colonne;
3. i tipi di dati;
4. i campi obbligatori e facoltativi;
5. i legami gerarchici tra azienda, reparto, area e altri livelli;
6. i campi adatti al filtraggio;
7. i campi adatti a KPI, classifiche e visualizzazioni;
8. i campi utilizzabili come identificativo anonimizzato stabile di un lavoratore;
9. i possibili problemi del database di origine: valori vuoti, grafie diverse della stessa unità, formati di data disomogenei, duplicati, mescolanza di testo e numeri, nomi di colonna ambigui.

Per il database BSD individua separatamente dove si trovano:
- data e ora;
- azienda;
- reparto;
- area / unità interna;
- chi conduce il BSD;
- la mansione di questa persona;
- lavoratore / identificativo anonimizzato;
- tipo di comportamento sicuro o pericoloso;
- processo / tipo di lavoro;
- descrizione dell’osservazione;
- esito o reazione.

Dopo l’analisi:
- descrivi brevemente la struttura dei dati;
- proponi quali legami tra i campi vadano conservati;
- elenca i punti dubbi da confermare con l’utente;
- solo dopo la conferma proponi l’architettura della futura dashboard.

Non cercare di ricostruire i valori anonimizzati e non trarre conclusioni sull’identità di un lavoratore specifico.

Prompt 2. Architettura della dashboard sui dialoghi comportamentali di sicurezza

Sulla base della struttura confermata del file Excel anonimizzato, proponi l’architettura di una dashboard HSE autonoma sui dialoghi comportamentali di sicurezza.

Principio guida: ogni visualizzazione deve rispondere a una domanda gestionale concreta. Non aggiungere grafici solo per decorazione.

Prevedi:
1. i KPI chiave sul volume di BSD e osservazioni;
2. filtri per periodo;
3. una gerarchia dipendente azienda → reparto → area / unità interna;
4. un filtro per chi conduce il BSD;
5. un filtro per la mansione di questa persona;
6. la dinamica dei BSD per mese e/o per giorno;
7. il confronto tra aziende;
8. la TOP delle unità / aree;
9. la TOP di chi conduce i BSD;
10. la struttura del comportamento sicuro e pericoloso;
11. le categorie di osservazioni pericolose;
12. l’analisi dei processi / tipi di lavoro;
13. una classifica dei lavoratori il cui comportamento pericoloso è stato rilevato più volte;
14. la ricerca per lavoratore o identificativo anonimizzato;
15. lo storico dei BSD del lavoratore selezionato;
16. la possibilità di vedere se lo stesso tipo di comportamento pericoloso si è ripetuto per lo stesso lavoratore in date diverse, con responsabili diversi o in aree diverse;
17. l’export della selezione corrente in Excel.

Per ogni visualizzazione indica separatamente:
- a quale domanda del dirigente risponde;
- quali campi utilizza;
- dove deve portare il clic su un elemento del grafico.

Descrivi prima l’architettura a parole. Per ora non produrre codice.

Prompt 3. Creazione del primo HTML autonomo

Sulla base dell’architettura concordata, crea la prima versione autonoma della dashboard HSE interattiva.

Requisiti:
1. Il risultato è un unico file HTML.
2. Il file si apre in un normale browser senza installare software aggiuntivo.
3. In fase di sviluppo usa soltanto dati dimostrativi anonimizzati.
4. Aggiungi i KPI concordati, i filtri, le classifiche, la ricerca, i grafici interattivi e una tabella dei record di origine.
5. Non usare un backend.
6. Non usare API esterne.
7. Non caricare librerie da una CDN.
8. Tutte le librerie necessarie devono trovarsi all’interno dell’HTML.
9. La dashboard deve aprirsi e funzionare pienamente con Internet disattivato.
10. Non aggiungere telemetria, analisi delle visite o richieste di rete.
11. Organizza il codice in modo che in seguito si possa rimuovere l’insieme dimostrativo e collegare un Excel reale in locale.
12. Non modificare senza necessità gli identificativi anonimizzati esistenti dei lavoratori.

Dopo la creazione:
- elenca le funzioni realizzate;
- elenca i limiti della prima versione;
- indica quali funzioni vanno verificate manualmente prima di proseguire.

Prompt 4. Caricamento locale del database di lavoro, azzeramento e copia offline

Migliora la dashboard HSE autonoma esistente.

Obiettivo: al termine dello sviluppo i dati dimostrativi devono essere rimossi dall’HTML e il database di lavoro reale deve essere collegato solo in locale, sul computer dell’utente.

Aggiungi le seguenti funzioni.

1. «Carica una nuova tabella»
- l’utente sceglie un file Excel sul proprio computer;
- il file viene letto dal browser solo in locale;
- i dati vengono caricati nella memoria della sessione corrente;
- KPI, filtri, grafici, classifiche e tabelle vengono ricostruiti completamente;
- la struttura viene determinata dalle intestazioni delle colonne, non da numeri di colonna fissi;
- in mancanza di un campo obbligatorio viene mostrato un messaggio di errore comprensibile.

2. «Applica filtri»
- ricalcolare tutte le visualizzazioni sulla selezione corrente.

3. «Azzera»
- svuotare solo i filtri selezionati;
- ripristinare la visualizzazione dell’intero database caricato;
- non cancellare i dati.

4. «Cancella tutti i dati»
- rimuovere completamente l’insieme di lavoro caricato dallo stato corrente dell’applicazione;
- svuotare KPI, grafici, classifiche, tabelle, cognomi / identificativi ed elenchi dei filtri;
- riportare l’HTML allo stato di involucro software vuoto.

5. «Esporta i dati selezionati in Excel»
- esportare solo la selezione filtrata corrente.

6. «Salva una copia offline»
- eseguire il salvataggio solo dopo un’azione esplicita dell’utente;
- se nella copia viene incorporato il database di lavoro corrente, mostrare un avviso che l’HTML salvato contiene dati di lavoro e va conservato come file riservato;
- durante il salvataggio nessuna informazione deve essere inviata in rete.

Se in seguito viene aggiunta una funzione di caricamento incrementale:
- verificare prima la struttura;
- non creare duplicati automaticamente;
- mostrare all’utente quanti record verranno aggiunti e quanti rifiutati.

Rimuovi completamente l’insieme dimostrativo dalla versione finale.

Prompt 5. Filtri dipendenti, cliccabilità e discesa fino al record

Migliora la dashboard HTML esistente senza riscriverla completamente.

Occorre:
1. Rendere i filtri dipendenti:
   azienda → reparto → area / unità interna.
2. Dopo la scelta dell’azienda, lasciare solo i reparti che le appartengono.
3. Dopo la scelta del reparto, lasciare solo le sue aree.
4. Tenere conto del periodo scelto, di chi conduce il BSD e della sua mansione.
5. Rendere cliccabili i grafici e le classifiche principali.
6. Al clic su una barra, un settore, un punto, una riga della classifica o un lavoratore, applicare la relativa selezione all’intera dashboard.
7. Mostrare i record di origine che hanno formato l’indicatore selezionato.
8. Aggiungere la possibilità di risalire di un livello o di azzerare il dettaglio corrente.
9. Aggiungere la ricerca per lavoratore / identificativo anonimizzato.
10. Per il lavoratore selezionato mostrare lo storico dei BSD nel periodo scelto: date, unità, chi ha condotto i BSD, tipi di comportamento, processi e record di origine.
11. Mostrare separatamente i lavoratori il cui comportamento pericoloso è stato rilevato più volte.
12. Consentire di vedere la ripetizione dello stesso tipo di comportamento pericoloso anche se è stato rilevato da responsabili o specialisti diversi e in aree diverse.
13. Esportare la selezione corrente in Excel.
14. Non modificare senza necessità le funzioni già funzionanti.

Dopo l’intervento esegui una verifica di regressione:
- tutti i filtri;
- i clic sui grafici;
- la ricerca;
- il dettaglio;
- l’export;
- il ritorno alla selezione completa.

Prompt 6. BSD + foglio presenze reale: rispetto della frequenza raccomandata stabilita

Aggiungi alla dashboard esistente una modalità di analisi dei BSD che tenga conto dei turni effettivamente lavorati.

Fonti:
- l’export dei BSD da Collab;
- il foglio delle ore lavorate dello stesso periodo.

In fase di sviluppo usa solo un modello anonimizzato del foglio presenze. Il foglio reale va collegato più avanti e solo in locale.

IMPORTANTE:
non inventare da solo la norma di esecuzione dei BSD. Prima del calcolo l’utente deve indicare la frequenza raccomandata stabilita, ad esempio:
- X BSD ogni N turni effettivamente lavorati;
- X BSD per periodo di calendario / di rendicontazione;
- un’altra regola dell’azienda.

Logica:
1. Determina i turni effettivamente lavorati in base al foglio presenze.
2. Non considerare turni effettivamente lavorati ferie, malattia e altre assenze.
3. Metti in corrispondenza l’insieme dei BSD e il foglio presenze tramite l’identificativo stabile del lavoratore, l’azienda, il reparto, l’area, la professione e il periodo — a seconda dei campi disponibili.
4. Non mescolare cognomi / identificativi e professioni uguali di unità diverse.
5. In base alla frequenza indicata dall’utente calcola il numero atteso di BSD per il tempo effettivamente lavorato.
6. Mostra:
   - i turni effettivamente lavorati;
   - la frequenza raccomandata stabilita;
   - il numero effettivo di BSD;
   - lo scostamento dalla frequenza raccomandata;
   - la percentuale di adempimento;
   - le unità e i lavoratori in ritardo.
7. Aggiungi la discesa:
   azienda → reparto → area → professione → singolo lavoratore → i suoi record BSD.
8. Consenti di esportare l’elenco dei lavoratori / delle unità con scostamento.

Se la struttura del foglio presenze o la regola di frequenza sono ambigue, mostra prima i casi dubbi e chiedi conferma. Non eseguire il calcolo prima della conferma.

Prompt 7. CRC + foglio presenze reale: regolarità dell’esecuzione e deviazioni

Aggiungi alla dashboard una modalità separata di analisi del controllo dei rischi critici (CRC).

Fonti:
- l’export dei CRC da Collab;
- il foglio reale delle ore lavorate dello stesso periodo.

In fase di sviluppo usa modelli anonimizzati. Gli insiemi reali vanno collegati solo in locale.

Logica:
1. Determina i turni effettivamente lavorati da ciascun lavoratore.
2. Non considerare turni di lavoro ferie, malattia e altre assenze.
3. Non inventare da solo la norma / la regolarità richiesta dei CRC. Ottienila dall’utente come parametro.
4. Se per un determinato processo è confermato il requisito «1 CRC per turno effettivamente lavorato», usalo solo dopo la conferma dell’utente.
5. Metti in corrispondenza i CRC con i turni effettivamente lavorati tramite l’identificativo stabile, l’azienda, il reparto, l’area, la professione, la data e/o il turno.
6. Non mescolare professioni e identificativi uguali di unità diverse.
7. Per ogni lavoratore mostra:
   - i turni effettivamente lavorati;
   - il numero di CRC;
   - i turni / periodi in cui manca un CRC rispetto alla regola indicata;
   - lo scostamento;
   - la percentuale di adempimento.
8. Aggiungi la discesa:
   azienda → reparto → area → professione → lavoratore → turno specifico / record CRC specifico.
9. Consenti di esportare l’elenco dei lavoratori o dei turni con scostamento.
10. Se nell’export dei CRC sono presenti pericoli individuati, rischi critici, descrizioni di deviazioni o cause, mostra inoltre:
   - la ricorrenza per area;
   - la ricorrenza per processo;
   - la ricorrenza per lavoratore;
   - i record di origine al clic.

Se la struttura dei dati è ambigua, mostra prima le regole di corrispondenza e i casi dubbi. Non eseguire il calcolo finale prima della conferma dell’utente.

Prompt 8. Diagnosi dei difetti e autoverifica tecnica

Esegui una verifica della dashboard HTML autonoma esistente.

All’inizio non riscrivere l’intera applicazione.

Se dopo l’ultimo intervento è comparso un errore:
1. Trova la causa specifica.
2. Correggi solo la parte necessaria.
3. Non eliminare né riscrivere senza motivo le funzioni già funzionanti.
4. Dopo la correzione esegui una verifica di regressione.

Verifica obbligatoriamente questi scenari:
- apertura dell’HTML senza Internet;
- caricamento di un Excel di prova anonimizzato;
- filtri dipendenti;
- clic e discesa;
- ricerca per lavoratore;
- export della selezione scelta;
- azzeramento dei filtri;
- cancellazione completa dei dati;
- nuovo caricamento di un’altra tabella;
- salvataggio di una copia offline.

Dopo la verifica funzionale esegui un audit dell’autonomia e dei possibili canali di trasmissione / archiviazione:
- fetch;
- XMLHttpRequest;
- WebSocket;
- EventSource;
- sendBeacon;
- script src esterni;
- CDN;
- CSS e font esterni;
- API;
- iframe;
- Service Worker;
- localStorage;
- sessionStorage;
- IndexedDB;
- cookie;
- telemetria e analytics.

La versione finale deve:
- funzionare pienamente con Internet disattivato;
- non inviare in rete il contenuto dei file Excel caricati;
- non salvare il database di lavoro in modo nascosto senza un’azione esplicita dell’utente;
- in caso di azzeramento completo, rimuovere i dati di lavoro dallo stato corrente dell’interfaccia.

Alla fine fornisci un breve rapporto:
1. che cosa è stato verificato;
2. quali difetti sono stati trovati;
3. che cosa è stato corretto;
4. quali limiti o rischi permangono.

Ordine d’uso consigliato

1. Eseguire il Prompt 1 e verificare se l’IA ha compreso correttamente la struttura dell’Excel anonimizzato.
2. Dopo la conferma della struttura, eseguire il Prompt 2.
3. Eseguire il Prompt 3 e ottenere la prima versione HTML autonoma.
4. Man mano che si procede, usare il Prompt 5 per filtri, clic e discesa.
5. Quando la logica è pronta, eseguire il Prompt 4: rimuovere i dati dimostrativi e organizzare il caricamento locale del database di lavoro, gli azzeramenti, l’export e la copia offline.
6. Se serve l’analisi della frequenza raccomandata dei BSD, collegare il Prompt 6.
7. Per i CRC e il confronto con il foglio presenze reale, usare il Prompt 7.
8. Dopo modifiche rilevanti e prima della pubblicazione / consegna agli utenti, eseguire il Prompt 8.