# Gray areas registry | ID | Area | Gap descrizione | Evidenza gia presente | Evidenza mancante | Metodo verifica | Owner consigliato | Priorita | Impatto | Costo | Rischio | Stato | Criterio di chiusura | |---|---|---|---|---|---|---|---|---|---|---|---|---| | GA01 | Core Yii e customizzazioni Sophia | Il perimetro esatto delle personalizzazioni di framework e documentato, ma la copertura end-to-end tra codice, note storiche e comportamento atteso non e ancora completamente formalizzata | `structure_and_functions.md`, `sophia_customizations.md`, `07_differenze_cross_app.md` | Mappa univoca di feature core, versione e punti di estensione realmente canonizzati | Revisione guidata dei documenti base e confronto con i repository consumatori | Referente framework + analista tecnico | Alta | Alto | Medio | Medio | pronto verifica | Il set delle customizzazioni core e tracciato con riferimenti univoci e stato d'uso | | GA02 | Grid, filtri e rendering | Le regole di rendering di griglie, filtri e colonne sono descritte, ma resta da normalizzare la distinzione tra comportamento base, override Sophia e casi legacy | `structure_and_functions.md`, `07_differenze_cross_app.md`, registry cross-app | Tassonomia completa delle varianti e dei casi legacy ancora ammessi | Lettura comparata di view, widget e helper lato grid | Sviluppo front-end + referente framework | Alta | Alto | Medio | Medio | pronto verifica | Ogni variante di grid ha una classificazione e un criterio di uso documentato | | GA03 | Error handling e debug | La gestione errori e documentata, ma non e ancora esplicitato in modo completo il confine tra output di debug, logging e contenuti ammessi in produzione | `structure_and_functions.md`, `10_migliorie_sicurezza.md` | Policy unica per messaggi al browser, log file e ambienti | Verifica configurazioni e riscontro con casi di errore reali | Referente sicurezza + backend | Alta | Alto | Basso | Medio | pronto verifica | La policy di esposizione errori e documentata e verificata su ambiente di test | | GA04 | Sessione e cache-control | La documentazione cita `CHttpSession` e le protezioni browser-back, ma i flag cookie e le regole di timeout non sono chiusi a livello documentale | `structure_and_functions.md`, `10_migliorie_sicurezza.md` | Configurazione puntuale di `Secure`, `HttpOnly`, `SameSite`, timeout e rigenerazione ID | Audit config e test di login/logout e navigazione back | Referente infrastruttura + security | Alta | Alto | Medio | Medio | open | La policy sessione/cookie e confermata per ogni ambiente documentato | | GA05 | RBAC, menu e azioni sensibili | Il layer di autorizzazione e noto, ma non esiste ancora una matrice completa menu -> controller -> action -> controllo server-side per tutte le app consumatrici | `cross_app_capability_registry.md`, `10_migliorie_sicurezza.md` | Elenco completo delle action sensibili con controllo esplicito | Review config e test di accesso negato sulle aree admin | Referente security + referente applicativo | Alta | Alto | Medio | Medio | open | Ogni action sensibile ha controllo server-side e riferimento al ruolo richiesto | | GA06 | Configurazione e ambienti | La separazione per ambiente e documentata, ma il perimetro dei segreti e delle differenze non uniformate non e ancora completamente inventariato | `configuration_and_environments.md` richiamato in 10, note su config nei documenti base | Inventario di file, parametri e differenze ambiente con classificazione sensibilita | Audit config e confronto tra dev, test, preprod e prod | DevOps + referente framework | Alta | Alto | Medio | Medio | open | I file e i parametri critici sono catalogati con owner e sensibilita | | GA07 | Pattern `frm/app/cli` | Il pattern e descritto come tassonomia base, ma resta da consolidare quando un prefisso e core, quando e riuso e quando e estensione cliente-specifica | `07_differenze_cross_app.md`, `cross_app_capability_registry.md` | Regole di classificazione stabili e criteri di naming formalizzati | Rilettura comparata dei controller e dei registry cross-app | Analista tecnico + maintainer | Media | Medio | Basso | Basso | chiuso | Il pattern e classificato e gli esempi ricorrenti sono già normalizzati | | GA08 | Registry cross-app decisionale | Il registry esiste, ma il passaggio da descrizione a decisione operativa non e ancora completamente standardizzato | `cross_app_capability_registry.md`, `08_migliorie_app.md`, `09_migliorie_performance.md` | Regola univoca che dica come trattare `standard`, `piu aggiornata`, `da confermare` | Revisione delle note operative e consolidamento della legenda | Referente documentazione | Media | Medio | Basso | Basso | chiuso | Il registry e usabile come fonte decisionale e non solo descrittiva | | GA09 | Riuso sulle app verticali | La relazione tra baseline framework e app verticali e chiara, ma alcune equivalenze funzionali restano da confermare per assenza di evidenza diretta nel corpus | `07_differenze_cross_app.md`, `08_migliorie_app.md` | Elenco puntuale delle corrispondenze ancora solo inferite | Verifica mirata su controller/model/view delle app consumatrici | Analista cross-app + referente app verticali | Media | Medio/Alto | Medio | Medio | pronto verifica | Le equivalenze piu importanti sono confermate o marcate stabilmente come inferenze | | GA10 | Lineage documentale e ticket | La documentazione richiama storicita e note pregresse, ma non tutto il lineage dei ticket e dei cambi e ancora consolidato nel corpus base | `sophia_customizations.md`, `07_differenze_cross_app.md`, README | Catalogo stabile di riferimenti ticket -> modifica -> documento | Raccordo tra note, changelog e documentazione analitica | Analista tecnico + release manager | Bassa | Medio | Medio | Basso | pronto verifica | Il lineage minimo necessario e tracciato e richiamabile in modo univoco | ## Note uniformita - `open` indica gap reale con evidenza ancora insufficiente. - `pronto verifica` indica gap circoscritto, con evidenze gia presenti ma non ancora chiuso da conferma operativa. - `chiuso` indica gap gia chiuso a livello documentale per il perimetro di questa analisi. - Gli ID `GAxx` sono stabili e vanno usati come riferimento nel resto dell'analisi. ## Scopo Descrivere obiettivo operativo e risultato atteso. ## Perimetro Definire modulo, confini funzionali e prerequisiti. ## Flusso 1. Input e contesto. 2. Esecuzione del processo. 3. Output e verifica. ## Componenti - Controller/servizi. - Model e tabelle. - Job/log/integrazioni correlate. ## Failure mode - Errori ricorrenti. - Cause tipiche. - Segnali diagnostici. ## Checklist - Pre: prerequisiti validati. - Post: outcome e coerenza dati verificati. ## Criteri di accettazione Contenuto azionabile, verificabile e coerente con il codice.