Le regole che nascono dalle risposte.

Carriera amministrativa studenti

Gestisce la posizione amministrativa dello studente e le richieste conoscitive o operative collegate alla segreteria studenti.

• certificati di iscrizione, frequenza e attestati
• tasse, contributi, scadenze amministrative
• diritto allo studio, agevolazioni, sport e convenzioni
• stato pratica, modulistica, contatti e orari

Carriera didattica studenti

Gestisce la carriera didattica: percorso formativo, attivita didattiche, esami e richieste che richiedono istruttoria didattica.

• piani di studio e percorsi formativi
• lezioni, calendari didattici, esami
• frequenza e presenze al singolo corso con obbligo di frequenza
• verbalizzazioni e commissioni
• riconoscimento crediti e trasferimenti come orientamento guidato

Protocollo, AOO e flussi documentali

Collega ente, AOO, UO e uffici al perimetro documentale. Serve a sapere dove passa la pratica, senza trasformare il protocollo in helpdesk pubblico iniziale.

• ente IPA CMDC_AV: Conservatorio di Musica 'D. Cimarosa' di Avellino
• AOO IPA A009176, cod_aoo Presidente
• UO IPA KFYBVW, NBECRO, UF2UQQ
• raccordo protocollo e fascicolo pratica
• snapshot AOO nel routing del ticket

Setup e permessi in emergenza

Setup non coerente, coda attiva senza responsabile primario, operatori non autorizzati, seed o policy base mancanti.

• Se il gate fallisce si blocca tutto il lavoro non urgente, non solo le nuove aperture pubbliche.
• Il report emergenza setup e visibile ad amministratori helpdesk e responsabili di coda.
• Se una coda resta senza responsabile primario, il Direttore amministrativo e fallback temporaneo proposto.
• SPEM-01 ha un comando/check dedicato.

• Eseguire check_helpdesk_setup e bloccare il lavoro non urgente se il gate non e OK.
• Ripristinare responsabile primario e membership minime sulle code attive.
• Usare seed idempotente solo su dati reali enti/IPA, senza creare utenti inventati.
• Mostrare il report emergenza a responsabili e amministratori.
• Usare check_helpdesk_emergency --spem=01 come comando dedicato.
• Produrre report rapido con conteggi, code scoperte e rotte staff da verificare.

check_helpdesk_setup torna OK, tutte le code attive hanno responsabile primario e gli operatori staff vedono solo code autorizzate.

Arretrati, sovraccarico e recupero coda

Ticket non presi dopo 32h+1m, picco arretrati, operatori saturi o rilascio massivo al responsabile.

• L autoassegnazione parte in dry-run, poi puo diventare automatica programmata dopo conferma amministrativa.
• Se tutti gli operatori sono sopra soglia 10, il ticket va al responsabile primario.
• Non nasce una nuova pagina: si potenzia /helpdesk/staff/arretrati/.
• SPEM-02 ha un comando/check dedicato.

• Eseguire auto_assign_helpdesk_tickets in dry-run e far leggere il piano a responsabile/admin.
• Materializzare con --commit solo le assegnazioni coerenti.
• Usare /helpdesk/staff/arretrati/ come pagina figlia di recupero.
• Separare casi rilasciati al responsabile da casi autoassegnati al meno pieno.
• Usare check_helpdesk_emergency --spem=02 come comando dedicato.

nessun ticket resta oltre soglia senza assegnazione o piano manuale motivato nel relativo audit.

Privacy, consultazione pubblica e dati riservati

Ticket con dati sensibili, consultazione pubblica da disattivare, rischio leak, nota interna da rendere pubblica solo dopo depurazione.

• Tutti gli operatori autorizzati possono segnalare/classificare, poi il ticket diventa visibile solo ai gradi piu alti.
• Se il ticket diventa segreto, la consultazione pubblica email+codice si disattiva sempre in automatico.
• La depurazione di una nota interna richiede doppia conferma autore piu responsabile.
• Sono ammesse depurazioni generiche preautorizzate da lista.
• SPEM-03 ha un comando/check dedicato.

• Disabilitare public_lookup_enabled o classificare il ticket come riservato/segreto.
• Verificare markup pubblico con test anti-leak prima di qualunque riapertura pubblica.
• Consentire pubblicazione di note interne solo tramite depurazione autorizzata e audit.
• Gestire lista di depurazioni generiche preautorizzate per casi semplici.
• Usare check_helpdesk_emergency --spem=03 come comando dedicato.
• Tenere allegati reali fuori dal perimetro finche SPEM non ha storage/antivirus/retention approvati.

la pagina pubblica non espone dati interni o riservati, il ticket ha classificazione corretta e ogni oscuramento e auditato.

Core unico e mono-modulo

Il modulo Django si chiama helpdesk, vive in backend/src/helpdesk, parte dal Conservatorio Cimarosa e usa codice ticket HD-YYYY-NNNNNN.

• un solo core generico
• setup ente obbligatorio
• codice ticket non dipendente dalla coda

Due code MVP

Il primo perimetro operativo usa Segreteria studenti e Segreteria didattica, con categoria che instrada alla coda e fallback da assegnare.

• queue obbligatoria sul ticket
• presa in carico personale successiva
• routing correggibile

Richiedenti plurali

Il richiedente puo essere studente, cittadino/pubblico, stakeholder, fornitore, personale interno o operatore per conto terzi.

• tipo richiedente obbligatorio
• matricola facoltativa
• operatore e richiedente tracciati separatamente

Conversazione separata dal lavoro interno

Messaggi pubblici, note interne, eventi audit e allegati pubblici/interni restano livelli distinti del ticket.

• primo messaggio pubblico dalla descrizione
• note interne non esposte
• audit eventi non modificabile

Privacy a doppio click

Apertura bloccata senza presa visione informativa e consenso; testo privacy e ricevuta sono snapshot versionati sul ticket.

• due conferme obbligatorie
• versione privacy salvata
• ricevuta salvata anche senza email reale

Allegati preparati ma non pubblici nel MVP

Il modello allegati entra subito, ma upload pubblico resta rinviato finche sicurezza e neutralizzazione rischi non sono definite.

• 5 file per ticket
• 10 MB per file
• visibilita pubblica/interna
• blocco formati pericolosi

Ruoli a catena

Operatore, responsabile coda, amministratore helpdesk e superuser hanno poteri crescenti; gli stati pubblici usano una regola mista tra automatismi e comando autorizzato.

• operatore incaricato avanza ticket ordinari
• responsabile presidia eccezioni
• admin oscura su proposta
• stati interni non sempre visibili

Riassegnazione governata per linea

Categoria e coda si possono correggere, ma la riassegnazione segue linea di competenza, privacy e ruolo autorizzato.

• stessa linea: responsabile
• linee diverse: amministratore
• privacy: decisione responsabile/admin

Urgenza guidata, priorita fuori MVP

La priorita interna resta fuori MVP, ma presa in carico e prima risposta non sono piu teoriche: il setup gestisce 32 ore, 48 ore, urgenza 24 ore e limite operatore; S19 applica la presa in carico mancata a 32h+1m.

• presa in carico 32h+1m
• prima risposta 48 ore
• urgenza valutata entro 24 ore
• sospensioni e calendari avanzati restano S20

Escalation arretrati

La prima emergenza arretrati e ora governata: se nessuno prende in carico dopo 32h+1m il sistema assegna al meno pieno, usa soglia 10 e ricade sul responsabile primario se operatori assenti o saturi. Escalation amministratore/super amministratore resta step successivo.

• autoassegnazione S19
• badge arretrato staff
• fallback responsabile
• SPEM-02 per picco arretrati e recupero operativo

Riapertura senza reset

La riapertura non cancella ne' azzera la storia: conserva tutto e aggiunge eventi, tempi e stati separati.

• storico completo
• KPI riapertura dedicati
• prima chiusura e riaperture misurate separatamente

Accesso progressivo

Il MVP usa email piu codice ticket, ma la consultazione pubblica resta temporanea: massimo 30 giorni o fino al collegamento in area personale.

• consultazione pubblica temporanea
• nessun account obbligatorio iniziale
• messaggio dopo 30 giorni
• migrazione futura da preparare

Conservazione con esclusione auditata

Il ticket conserva la storia con audit; S17 ha reso coerenti chiusura, riapertura e archiviazione collaudi. La minimizzazione/depurazione di contenuti sensibili resta governata come emergenza SPEM-03 prima della pubblicazione di note o allegati reali.

• conservazione completa
• archiviazione sicura collaudi
• classificazione riservatezza
• SPEM-03 per leak o dati sensibili

Ricevuta minimizzata e correggibile

La ricevuta deve salvare dati minimi, riepilogo breve e istruzioni per correzione o integrazione, soprattutto quando l operatore apre per conto di qualcuno.

• riepilogo massimo 10 parole
• area/servizio invece di coda interna
• form correzione o integrazione
• snapshot notifiche rilevanti

Dashboard agile a tre corsie

La dashboard staff e diventata codice: S18 ha introdotto madre e pagine figlie Da prendere, In scadenza, Arretrati e Miei ticket; S19 aggiunge badge Autoassegnato, Rilasciato e Arretrato.

• Da prendere
• In scadenza
• Arretrati
• Miei ticket
• badge S19
• vista responsabile/admin senza board enorme

Schema simulato prima della migrazione

Prima dello sviluppo reale lo schema viene espresso come SQL simulato su pagina pubblica di lavoro, cosi tabelle e vincoli sono discutibili senza toccare il database.

• nessuna migrazione generata
• DDL PostgreSQL leggibile
• relazioni verificabili
• base per modelli Django futuri

Policy configurabili, non valori hardcoded

La base non e piu solo bozza: esistono setup istituzione, SLA policy, category entry rule e membership. Restano da rendere piu ricche le policy stati/categorie/permessi, con SPEM-01 come paracadute se il setup risulta incoerente.

• InstitutionSetup reale
• SlaPolicy reale
• CategoryEntryRule reale
• mapping stato interno/pubblico da estendere
• S20 per setup ricco

Ticket come fascicolo conversazionale

Il ticket madre non e solo una richiesta: conserva messaggi, note, allegati, assegnazioni, ricevute, consensi e audit come fascicolo minimo.

• ticket centrale
• tabelle figlie append-only dove possibile
• eventi audit sempre separati
• riapertura come evento

Privacy e riservatezza come livelli dati

La riservatezza non e un testo libero: serve livello classificato sul ticket e sugli allegati, includendo anche il livello segreto, con regole di visibilita, minimizzazione e log accesso.

• sensitivity_level sul ticket
• livello segreto previsto
• visibility_scope sugli allegati
• access log minimizzato
• oscuramento auditato

Segreteria studenti e didattica distinte nel routing

La coda helpdesk deve distinguere carriera amministrativa e carriera didattica, restando collegabile a organigramma e funzionigramma senza far scegliere uffici tecnici al pubblico.

• queue collegata a ufficio/funzione
• categoria come ingresso pubblico
• area/servizio in ricevuta
• storico anche se organigramma cambia

Base ente, AOO e organigramma shared

Il MVP parte dal Conservatorio Cimarosa come ente unico, ma il modello resta multi-ente. Il dato reale IPA verificato usa codice ente CMDC_AV, AOO A009176 e UO KFYBVW, NBECRO, UF2UQQ: la pagina non deve usare dati fittizi o denominazioni di comodo.

• FK verso enti.PublicEntity
• AOO A009176 come profilo dedicato
• UO IPA reali nel seed
• validita storica obbligatoria
• dipartimenti didattici fuori MVP

Funzionigramma sintetico ed esteso

Il pubblico vede solo un funzionigramma sintetico. Il backend/setup conserva il funzionigramma esteso con funzioni, responsabilita, relazioni ufficio-funzione e validita temporale; le funzioni iniziali sono carriera amministrativa studenti, carriera didattica studenti e protocollo/AOO come funzione di raccordo documentale.

• vista pubblica minimale
• setup esteso riservato
• funzioni iniziali seedate
• funzioni storicizzate
• ruoli responsabile/istruttore/supporto/approvatore

Coda collegata a ufficio e funzione

La coda non coincide con l ufficio: e il contenitore operativo dei ticket. Ogni coda punta a un ufficio responsabile e a una funzione prevalente; ogni categoria puo puntare a una funzione per spiegare perche la richiesta viene instradata li.

• ufficio = responsabilita operativa
• funzione = cosa viene chiesto
• coda = lavoro ticket
• snapshot routing sul ticket

Seed mono-ente pronto per multi-ente

Il seed parte dal solo Conservatorio Cimarosa, ma non deve nascere come scorciatoia mono-ente: ogni record deve puntare all ente e restare idempotente, rilanciabile e non distruttivo verso modifiche admin.

• CMDC_AV come ente iniziale
• A009176 usabile e aggiornabile da IPA
• due code pubbliche iniziali
• privacy ordinaria di default
• seed update-or-create non distruttivo

Certificazioni studenti distinte da frequenza didattica

Certificati di iscrizione, certificati di frequenza e atti certificativi sono carriera amministrativa e vanno in Segreteria studenti. Le presenze o la frequenza al singolo corso con obbligo di frequenza restano carriera didattica e vanno in Segreteria didattica.

• categoria certificati -> Segreteria studenti
• categoria presenze corso -> Segreteria didattica
• template pubblici separati
• niente confusione tra certificato e registro frequenza

Categorie MVP con ingresso informativo

Le categorie MVP non devono aprire sempre un ticket: alcune mostrano prima informazione, modulistica o contatti; il ticket nasce solo quando resta un caso personale, una pratica o un dubbio non risolto.

• category_entry_rule
• informazione prima del ticket
• campi progressivi per pratica e corso
• riduzione richieste inutili

Casi delicati lavorabili senza dati riservati

Crediti, trasferimenti, piani complessi, ricorsi, disciplinari, contenzioso e richieste economiche particolari possono essere orientati o pre-lavorati, ma nel primo setup non devono raccogliere dati riservati.

• orientamento o pre-triage controllato
• warning dati sensibili
• conversione a ticket solo autorizzata
• metriche minimizzate

Privacy standard, mailbox e bozza risposta

Il DPO predisporra il testo definitivo quando serve; per ora si usa informativa standard. Il sistema prevede avviso dati sensibili, mailbox per servizio piu mailbox generale errori e bozza risposta prima dell invio ufficiale.

• privacy interim standard
• sensitive warning prima invio
• service mailbox configurabile
• reply draft prima del messaggio ufficiale

Sprint 1 operativo minimo

Sprint 1 include core minimo e setup essenziale, non esteso: migrazioni, seed idempotente, admin per code/categorie/regole/testi/SLA, form pubblico senza allegati/email/login, lista operatore semplice e azioni minime.

• InstitutionSetup e policy minime
• seed dry-run prima di --commit
• nessun utente reale inventato
• consultazione email+codice rinviata
• DoD: migrazioni, seed, admin, form, test, smoke route, report e commit pulito

Sprint 2 preparato come consultazione pubblica stretta

Sprint 2 e stato portato nel codice come consultazione pubblica stretta: pagina /helpdesk/consultazione/ con email, codice e cognome; vista solo pubblica del ticket; ricevuta HTML; errori generici; log minimizzato e blocchi progressivi.

• rotta pubblica /helpdesk/consultazione/
• solo parte pubblica del ticket
• terzo controllo cognome
• codice normalizzato
• email case-insensitive
• ticket riservati/segretati esclusi dalla consultazione pubblica

Integrazione e riapertura predisposte ma non invasive

L integrazione pubblica del richiedente e la richiesta di riapertura sono funzioni certe ma da attivare con calma: prima consultazione read-only, poi integrazione con warning, privacy extra per dati sensibili ed evento interno di attenzione.

• integrazione pubblica rinviabile allo step successivo
• riapertura non automatica
• prima riapertura operatore con notifica responsabile
• flag dati sensibili con conferme aggiuntive
• evento interno per coda quando arriva integrazione

Sicurezza accesso pubblico minimizzata

La consultazione pubblica usa controllo email+codice+cognome, 5 tentativi, blocchi 10/30 minuti e poi sblocco umano; accessi e tentativi sono loggati con hash e dati tecnici ridotti per 30 giorni.

• messaggio errore sempre generico
• IP minimizzato
• user agent ridotto
• hash email/codice/cognome
• retention log 30 giorni
• anti-spam minimo solo sperimentale

FAQ before ticket per categorie informative

Le categorie information_first devono mostrare prima una pagina informativa o FAQ con orari, calendario accademico, ricevimento uffici, contatti, tasse, scadenze, modulistica e regolamenti; se non basta, si apre ticket sulla categoria.

• pagina informativa prima del ticket
• CTA apri ticket su questa categoria
• riduzione ticket inutili
• testi minimi configurabili

Dashboard leggera con ingressi filtrati

La scrivania operatore resta semplice: lista principale piu ingressi filtrati. La base S2 aveva tre pulsanti/figlie Da prendere, In scadenza e Arretrati; S18 integra la quarta corsia Miei ticket senza trasformarla in board completa.

• lista principale semplice
• ingressi filtrati come pagine figlie
• quarta corsia Miei ticket in S18
• responsabile vede propri ticket e collaboratori
• amministratore vede tutte le code

Preparazione Sprint 2 senza avvio sviluppo

Le rifiniture S7 hanno chiuso mockup e vincoli minimi; poi S2 ha attivato la consultazione pubblica e S18 ha aperto la scrivania staff. Questa logica resta come memoria di perimetro: niente pubblico nuovo finche backend/staff non e stabile.

• nessuna migrazione generata da S7
• rotta Django S2 attivata dopo il via esplicito
• mockup e logiche pronti per il kickoff
• perimetro S2 ristretto e verificabile

Mockup pubblico S2 essenziale

La UX pubblica minima e presente su /helpdesk/consultazione/ e mantiene il vincolo forte: mostrare solo parte pubblica, ricevuta e messaggi pubblici, senza note interne, audit o stati interni.

• form consultazione compatto email/codice/cognome
• link e box secondario dalla pagina nuovo ticket
• ricevuta HTML con stampa browser pulita
• badge e colori per distinguere interlocutorio e risposta ufficiale

Accessi pubblici separati dai tentativi errati

Ogni accesso riuscito viene registrato in PublicAccessLog, mentre i tentativi errati o bloccati stanno in PublicAccessAttempt. Il rate-limit usa email, codice, cognome normalizzati e IP minimizzato.

• log riusciti e tentativi separati
• conteggio ogni accesso
• chiave blocco normalizzata
• privacy by design su IP e identificativi

Eventi pubblici come badge operatore

Quando integrazioni, dati sensibili o richieste di riapertura entreranno nel flusso, dovranno creare eventi interni visibili in lista con badge e contatori, senza trasformare subito la dashboard in board complessa.

• flag dati sensibili anche nei messaggi
• richiesta riapertura come evento da valutare
• badge Nuova integrazione e Richiesta riapertura
• pulsanti Da prendere/In scadenza/Arretrati con contatore eventi

Gate minimo Sprint 2

Il gate leggero e diventato pratica: test Django mirati, smoke route manuale, report, commit e push. Da S18-S19 il visual gate Playwright entra quando si toccano dashboard o template staff.

• test Django bloccanti
• smoke route manuale obbligatorio
• report finale obbligatorio
• Playwright rinviato, non cancellato

Ready Sprint 2 esecuzione

Le 10 conferme finali hanno trasformato S2 da proposta a codice: consultazione pubblica read-only, rotta stabile, campi obbligatori, visibilita pubblica minima, esclusioni privacy, modelli minimi, test bloccanti e DoD.

• S2 eseguibile solo come read-only
• nessun codice ticket nell URL pubblico
• TicketPublicView come read model/service
• test bloccanti definiti prima della migrazione
• avvio codice subordinato a via esplicito

Sicurezza service-side Sprint 2

S9 blinda la vista pubblica: errore generico, log senza dati in chiaro, TicketPublicView centralizzato, stati pubblici mappati, esclusione dati interni a livello service, disattivazione manuale e test anti-leak HTML.

• errore pubblico sempre generico
• log pubblici senza email/codice/cognome in chiaro
• service unico TicketPublicView
• esclusione dati interni a livello service
• test negativo su HTML pubblico

Assegnazioni come storico correlato

Il ticket resta fascicolo aggregatore; la presa in carico nominale, i cambi, le motivazioni e la validita temporale stanno in HelpdeskTicketAssignment. Esiste una sola assegnazione attiva per ticket, mentre le precedenti restano storicizzate.

• ticket non trasformato in mega-tabella
• una sola assegnazione attiva
• precedenti assegnazioni chiuse con motivazione
• scheda staff con storia recente
• audit su cambio assegnazione

Responsabile primario e fallback operativo

Ogni coda attiva deve avere un responsabile primario reale. Il sistema non crea operatori inventati; se nessuno prende in carico dopo la soglia configurata, autoassegna al meno carico della coda o al responsabile primario quando mancano operatori disponibili o sono saturi. Nel runtime il blocco e risolto: luigi.dalessandro presidia Segreteria studenti e francesca.manganiello presidia Segreteria didattica.

• responsabile primario obbligatorio per coda attiva
• blocco responsabili primari mancanti risolto nel runtime
• seed senza utenti fittizi
• soglia presa in carico dal setup
• limite carico operatore configurabile
• check_helpdesk_setup OK=True dopo configurazione responsabili

Permessi staff su ticket assegnato

Le azioni staff seguono assegnazione e ruolo: operatore assegnato lavora il ticket, responsabile e amministratore supervisionano, il rilascio al responsabile richiede motivazione e le note interne restano filtrate per ruolo.

• azione pubblica solo per assegnato o supervisore
• rilascio motivato al responsabile primario
• intervento responsabile auditato
• note interne filtrate per ruolo
• DoD S15 con test, smoke, report, commit e push

Collaudo interno reale S16

S16 verifica il flusso reale interno su ticket HD-2026-000001: apertura controllata senza dati personali reali, presa in carico da operatore tecnico, nota interna riservata, rilascio motivato al responsabile primario e audit ricostruibile.

• ticket di test interno marcato collaudo
• presa in carico con assegnazione self_take_charge
• nota interna non pubblica
• rilascio release_to_responsible verso luigi.dalessandro
• storia assegnazioni e audit eventi verificabili

Ciclo chiusura, riapertura e collaudi S17

S17 completa il ciclo backend/staff senza aprire nuova UI pubblica: la chiusura ordinaria chiude anche l assegnazione attiva, la prima riapertura staff crea una nuova assegnazione presidiata e i ticket di collaudo sono archiviabili solo con doppio criterio sicuro e comando dry-run-first.

• chiusura ticket e chiusura incarico non restano divergenti
• audit assignment_closed distinto dalla chiusura del ticket
• prima riapertura staff limitata da reopened_count
• riapertura con nuova assegnazione attiva all operatore che riapre
• archiviazione collaudi solo se subject [COLLAUDO...] ed email @example.invalid
• comando archive_helpdesk_test_tickets dry-run di default e scrittura solo con --commit
• admin action prudente che salta ticket non sicuri
• nessuna nuova migrazione S17

Dashboard staff minima S18

S18 e ora codice Django: la dashboard staff usa un read model derivato, quattro ingressi filtrati, pagine figlie, ricerca rapida, filtri coda/stato e badge per assegnazioni, collaboratori ed eventi. Non introduce nuova migrazione e non apre nuova UI pubblica MM Prova.

• default su code autorizzate per operatore
• vista tutte le code per superuser o ruolo amministratore helpdesk
• corsie Da prendere, In scadenza, Arretrati e Miei ticket
• pagine figlie /helpdesk/staff/<corsia>/
• responsabile vede collaboratori con badge distinto
• amministratore helpdesk vede e lavora tutte le code
• massimo 5 ticket per corsia nella madre
• colonne compatte: codice, oggetto, coda, stato interno, assegnazione, eta, eventi
• ordinamento per urgenza operativa e anzianita
• ricerca rapida con codice normalizzato, email, cognome e oggetto
• filtri coda e stato interno nelle pagine figlie
• test S18 su operatore, responsabile, amministratore e filtri
• nessuna nuova UI pubblica MM Prova/helpdesk

Escalation e arretrati staff S19

S19 rafforza il motore operativo interno: presa in carico mancata a 32 ore piu 1 minuto, autoassegnazione al meno pieno nella stessa coda, soglia configurabile di 10 ticket attivi, fallback al responsabile, rilascio motivato e badge staff Autoassegnato/Rilasciato/Arretrato.

• nessuna nuova UI pubblica
• nessuna tabella duplicata per lo storico assegnazioni
• helpdesk_ticket_assignment resta la storia dell iter operativo
• autoassegnazione solo dopo soglia esatta 32h+1m
• meno pieno calcolato sui ticket attivi assegnati nella stessa coda
• soglia troppo pieno configurabile nel setup istituzione, default 10
• fallback al responsabile primario se operatori assenti o saturi
• stato interno assegnata quando il sistema crea incarico nominale
• rilascio al responsabile solo con motivazione obbligatoria
• dashboard staff arricchita con badge piccoli e non invasivi

SPEM-01 - Setup e permessi in emergenza

SPEM-01 serve quando il sistema non puo lavorare per setup incoerente: coda senza responsabile primario, membership mancanti, policy base assenti, seed non riallineato o permessi staff non coerenti. Se il gate fallisce si blocca tutto il non urgente e si riparte dai controlli gia sviluppati, non dal pubblico.

• check_helpdesk_setup come gate di emergenza
• blocco di tutte le nuove operazioni non urgenti
• report visibile ad amministratori helpdesk e responsabili di coda
• verifica responsabili primari per ogni coda attiva
• fallback temporaneo al Direttore amministrativo se manca il responsabile primario
• ripristino membership e permessi minimi da admin
• seed helpdesk idempotente solo se agganciato a dati reali enti/IPA
• comando operativo check_helpdesk_emergency --spem=01
• report rapido con rotte staff e conteggi setup

SPEM-02 - Arretrati, sovraccarico e recupero coda

SPEM-02 governa il picco arretrati: usa la base S19 per autoassegnare dopo 32h+1m, distribuire al meno pieno, fermarsi alla soglia 10 e rientrare al responsabile primario se tutti sono saturi. La corsia staff Arretrati va potenziata, senza creare una pagina concorrente.

• dry-run auto_assign_helpdesk_tickets prima di scrivere
• automatismo programmabile solo dopo conferma amministrativa
• ticket al responsabile primario se tutti gli operatori superano soglia 10
• potenziamento della corsia Arretrati esistente
• badge Autoassegnato/Rilasciato/Arretrato come segnale minimo
• nessuna email reale o automazione aggressiva in emergenza iniziale
• comando operativo check_helpdesk_emergency --spem=02
• chiusura emergenza solo con zero ticket oltre soglia o piano manuale motivato

SPEM-03 - Privacy, consultazione pubblica e dati riservati

SPEM-03 entra quando un ticket contiene dati riservati, rischio di esposizione pubblica, consultazione da bloccare o contenuto da depurare. Tutti possono segnalare la classificazione, ma dopo la marcatura la visibilita sale ai gradi piu alti; il livello segreto disattiva sempre la consultazione pubblica.

• disattivazione consultazione pubblica per ticket sensibile
• disattivazione automatica public_lookup_enabled per ticket segreto
• classificazione iniziale possibile a tutti gli operatori autorizzati
• visibilita successiva limitata a responsabili/admin/gradi piu alti
• classificazione riservato/ristretto/segreto da backend autorizzato
• verifica HTML pubblico anti-leak
• depurazione nota con doppia conferma autore piu responsabile
• depurazione generica consentita solo da lista preautorizzata
• comando operativo check_helpdesk_emergency --spem=03
• audit di ogni oscuramento o cambio visibilita
• allegati reali ancora fuori finche storage e sicurezza non sono pronti