# 07 - Differenze cross-app post analisi MySQL

## Piano iniziale

1. Definire il perimetro:
   - app corrente: `yii-framework-base`
   - altre applicazioni documentate e/o disponibili nel corpus locale: `yii-apk-ferrero`, `yii-gestione-interventi-la-quercia`, `yii-giie-alstom`, `yii-goc-olio-ferrari`, `yii-musa-app`, `yii-musa-alstom`, `yii-maf-alstom`, `yii-registri-iva-alstom`
2. Ricostruire le evidenze tecniche disponibili per il framework base:
   - documentazione locale su Yii core e customizzazioni Sophia
   - inventario controller/model nei repo sorgenti fratelli
   - eventuali registry gia presenti nelle analisi di altre app
3. Confrontare i capability cluster comuni:
   - autenticazione e RBAC
   - anagrafiche CRUD
   - documenti/workflow
   - questionari e moduli verticali
   - report/export/schedulazioni
   - customizzazioni di framework
4. Classificare ogni capability dell'app corrente:
   - piu aggiornata
   - standard/allineata
   - obsoleta
   - variante cliente-specifica
   - da confermare
5. Produrre un capability registry sintetico e una checklist verifiche eseguite.

## Contesto e perimetro confronto cross-app

`yii-framework-base` non e una business app verticale: e il riferimento documentale sul layer Yii/Sophia comune, quindi il confronto cross-app va letto come confronto tra:

- base framework e customizzazioni core;
- pattern riusati nelle app applicative Sophia;
- divergence funzionali osservabili nei domini verticali degli altri repo.

### Fonti tecniche usate

- `README.md`
- `structure_and_functions.md`
- `sophia_customizations.md`
- inventari controller/model nei repo sorgenti locali:
  - `yii`
  - `sophia_framework2`
  - `ferreroapk`
  - `musa_app`
  - `gestioneinterventi`
  - `goc`
  - `giie`
  - `registriva`
  - `maf-savigliano`
- analisi gia disponibili in altri repository documentali:
  - `../yii-apk-ferrero/analisi/07_differenze_cross_app.md`
  - `../yii-apk-ferrero/analisi/cross_app_capability_registry.md`

### App confrontate

| App | Ruolo nel confronto | Nota di affidabilita |
|---|---|---|
| `yii-framework-base` | app corrente / baseline di framework | evidenza alta sulla parte framework, bassa sulla parte funzionale verticale |
| `yii-apk-ferrero` | app verticale molto documentata | evidenza alta |
| `yii-gestione-interventi-la-quercia` | verticale operativo/interventi | evidenza media-alta |
| `yii-giie-alstom` | verticale fornitori/documenti/questionari | evidenza media-alta |
| `yii-goc-olio-ferrari` | verticale logistica/ordini/documenti | evidenza media-alta |
| `yii-musa-app` | verticale formazione/risk/skill | evidenza alta |
| `yii-musa-alstom` | solo tracce documentali pregresse | evidenza limitata, `da confermare` |
| `yii-maf-alstom` | corpus minimo nel materiale disponibile | `da confermare` |
| `yii-registri-iva-alstom` | corpus minimo nel materiale disponibile | `da confermare` |

## Matrice funzionalita comparate

| Macro-area | `yii-framework-base` | Pattern osservato nelle app verticali | Classificazione app corrente | Evidenza sintetica |
|---|---|---|---|---|
| Core Yii / framework | contiene documentazione su `CPagination`, `CCaptchaAction`, `CHtml`, `CHttpSession`, `CErrorHandler`, `CGridView`, `CGridColumn` | tutte le app applicative ereditano il layer base e le sue customizzazioni | `standard/allineata` | `structure_and_functions.md` e `sophia_customizations.md` descrivono estensioni core usate da tutto il corpus |
| Grid e filtri | documentata la catena griglia -> colonne -> JS `jquery.yiigridview.js` | molto usata in `musa_app`, `ferreroapk`, `gestioneinterventi`, `goc` | `piu aggiornata` sul layer tecnico, `standard/allineata` sul comportamento | i registry di Sophia mostrano piu commit sul layer grid rispetto ai moduli verticali |
| Error handling | documentati `CErrorHandler` e `framework/views/exception.php` | le app verticali dipendono da queste customizzazioni senza duplicarle | `standard/allineata` | comportamento comune, nessuna divergenza tecnica dimostrata |
| Sessione e browser back | documentato `CHttpSession` con cache-control esplicito | pattern riusato implicitamente dalle app con login e form multi-step | `standard/allineata` | evidenza diretta solo nel framework base |
| RBAC / ruoli | documentati i punti di estensione framework che le app sfruttano | app verticali espongono `RightsController`, `AuthitemController`, CRUGE o varianti | `standard/allineata` | il layer base e allineato al cluster Sophia |
| Anagrafiche CRUD | non sono presenti moduli business, solo pattern di base | quasi tutte le app hanno `FrmAna*`, `AppAna*`, `Cli*` e CRUD standard | `da confermare` per il perimetro corrente | il framework base non ha evidenza di una capability verticale propria |
| Documenti e workflow | non presenti come dominio business; presenti solo note sul framework e sulle estensioni core | in `apk`, `goc`, `gestioneinterventi`, `musa_app`, `registriva` sono capability centrali | `da confermare` | non esiste evidenza di controller/model/view business nel repo corrente |
| Questionari / survey | non presenti come capability verticale | presenti in `apk`, `giie`, `gestioneinterventi`, `goc`, `musa_app` | `da confermare` | nessuna prova nel repository corrente |
| Report, export, schedulazioni | documentati come estensioni tecniche del layer base, non come processi di business | usati nei verticali per stampe, report, job e export | `standard/allineata` | il framework base fornisce l'harness, le app verticali forniscono i casi d'uso |

## Schede differenza per funzionalita

### 1. Core Yii e customizzazioni Sophia

**Implementazione in `yii-framework-base`**

- Il corpus locale descrive il comportamento di `CPagination`, `CCaptchaAction`, `CHtml`, `CHttpSession`, `CErrorHandler`, `CGridView`, `CGridColumn` e del JS griglia.
- `sophia_customizations.md` elenca commit che spiegano la storia evolutiva delle personalizzazioni.

**Confronto cross-app**

- In `yii-apk-ferrero`, `yii-musa-app`, `yii-gestione-interventi-la-quercia`, `yii-goc-olio-ferrari`, `yii-giie-alstom` e `yii-registri-iva-alstom` si vedono controller e model costruiti sopra lo stesso impianto.
- I repository verticali mostrano un riuso sistematico del layer `frm/`, `app/`, `cli/`, del RBAC Sophia e delle griglie admin.

**Differenza principale**

- `yii-framework-base` e il livello di standardizzazione tecnica; le app verticali sono le consumatrici del pattern.
- Qui la "novita" non e funzionale ma infrastrutturale: il layer grid, error handling e paginazione risultano piu maturi del singolo modulo verticale medio.

**Classificazione**

- `piu aggiornata` per il layer tecnico di framework
- `standard/allineata` rispetto al comportamento atteso dalle app Sophia

**Nota tecnica**

- Questa classificazione e basata su evidenze locali di commit e documentazione; l'effettiva presenza del comportamento a runtime nelle app verticali e `da confermare` solo quando non esiste traccia nel loro codice/documentazione.

### 2. Anagrafiche CRUD

**Implementazione in `yii-framework-base`**

- Nessun modulo verticale specifico.
- Il corpus locale documenta solo i componenti base su cui gli altri repo costruiscono i loro CRUD.

**Confronto cross-app**

- `ferreroapk`, `musa_app`, `gestioneinterventi`, `goc`, `giie` e `registriva` mostrano inventari estesi di `FrmAna*`, `AppAna*`, `Cli*` e `Frm*` controller.
- Il pattern e molto uniforme: controller CRUD, model ActiveRecord, view `admin/_form/_search`.

**Differenza principale**

- Il framework base non presenta una capability comparabile a un'anagrafica di business; fornisce il supporto tecnico, non il dominio.

**Classificazione**

- `da confermare`

**Stato confronto**

- L'equivalenza funzionale non e dimostrata nel repo corrente.

### 3. Documenti, workflow e approvazioni

**Implementazione in `yii-framework-base`**

- La documentazione del repo base non espone un dominio documentale business.
- Sono documentate solo le primitive che gli altri moduli usano per implementarlo.

**Confronto cross-app**

- `ferreroapk` e `goc` hanno il cluster `AppDocumentiT`, `AppDocumentiR`, `AppDocumentiTWkf*`.
- `gestioneinterventi` usa `AppDocumentiTWkfController` e modelli dedicati ai documenti commessa/intervento.
- `musa_app` e `giie` hanno documenti integrati con formazione, segnalazioni e flussi fornitore.

**Differenza principale**

- Nel framework base il workflow e un servizio di piattaforma; nei verticali e una capability di business.

**Classificazione**

- `da confermare`

### 4. Questionari e moduli verticali

**Implementazione in `yii-framework-base`**

- Nessuna evidenza di controller/model/view specifici.

**Confronto cross-app**

- `apk`, `giie`, `gestioneinterventi`, `goc` e `musa_app` hanno sottodomini questionari ben distinti.
- In `apk` e `gestioneinterventi` i questionari sono molto integrati con documenti e workflow.
- In `musa_app` il perimetro si allarga a competenze, skill e formazione.

**Differenza principale**

- Nessuna capability verticalizzata nel repo corrente.

**Classificazione**

- `da confermare`

### 5. Report, export e schedulazioni

**Implementazione in `yii-framework-base`**

- Il corpus locale mostra che il framework base supporta il reporting e la griglia, ma non un processo business specifico.

**Confronto cross-app**

- Tutti i verticali hanno `ReportController`, `ReportExcelController`, `StampaController` o scheduler dedicati.
- `apk`, `goc` e `musa_app` hanno componenti specifici per stampe, export e job.

**Differenza principale**

- Il framework base e il punto di abilitazione; le app verticali sono il punto di applicazione.

**Classificazione**

- `standard/allineata`

## Stato app corrente

### Aree aggiornate

- Il layer tecnico Yii/Sophia risulta ben documentato e coerente con gli altri repo.
- Le personalizzazioni core su griglie, error handling, captcha, sessione e paginazione sono esplicitate con storia commit.

### Aree standard

- Il repo base e il riferimento comune per RBAC, rendering e widget di base.
- Le app verticali convergono sul medesimo impianto tecnico.

### Aree obsolete o non dimostrate

- Non emergono capability verticali proprie del repo corrente.
- Le equivalenze con anagrafiche, documenti, questionari o workflow sono `da confermare` per assenza di prova diretta.

## Divergenze giustificate vs divergenze da riallineare

### Divergenze giustificate

- Le app verticali hanno dominii diversi e quindi controller/model dedicati.
- Le customizzazioni del framework sono giustificate dal riuso trasversale e dal consolidamento delle griglie e dell'error handling.

### Divergenze da riallineare

- Se qualche app verticale usa ancora un pattern grid o sessione non allineato alle customizzazioni Sophia documentate qui, va verificato e normalizzato.
- Le differenze di naming tra `frm`, `app`, `cli` e namespace misti sono storiche; la coerenza va verificata caso per caso.

## Raccomandazioni operative prioritarie

### Quick win

- Usare questo repo come fonte canonica per le regole di griglia, error handling e sessione quando si analizzano le app verticali.
- Marcare in modo sistematico `da confermare` tutte le equivalenze non supportate da controller/model/view.

### Interventi medi

- Allineare la documentazione dei verticali alla tassonomia tecnica del framework base.
- Normalizzare il modo in cui vengono descritti i pattern `frm/app/cli` nei registry.

### Interventi strutturali

- Consolidare un registry comune delle capability Sophia con indicazione esplicita di dove il comportamento e core, dove e riusato e dove e cliente-specifico.

## Checklist verifiche eseguite

- [x] Letto il prompt `_prompts/07_differenze_cross_app.md`
- [x] Verificate le note tecniche locali `structure_and_functions.md` e `sophia_customizations.md`
- [x] Inventariati controller/model nei repo sorgenti fratelli
- [x] Confrontate le macro-aree comuni tra framework base e app verticali
- [x] Distinte evidenze dirette da inferenze, usando `da confermare` quando mancava prova
- [x] Verificato che il repository corrente non espone un dominio verticale business proprio

## Assunzioni, limiti e punti da validare con il team

- Il repository corrente e un hub documentale del framework, non una business app verticale.
- Il confronto cross-app qui e valido soprattutto come confronto di baseline tecnica.
- Non ho trovato nel repo corrente una traccia diretta di controller/model/view per anagrafiche, documenti o questionari: questa assenza va considerata un limite, non una prova assoluta di assenza nel codice storico esterno.
- Le app `yii-musa-alstom`, `yii-maf-alstom` e `yii-registri-iva-alstom` risultano insufficientemente espanse nei materiali disponibili, quindi ogni confronto con esse resta `da confermare`.
- Le informazioni su branch e ticket sono state usate solo quando presenti nelle note locali; dove mancavano prove, non ho forzato classificazioni.

## File modificati

- `analisi/07_differenze_cross_app.md`
- `analisi/cross_app_capability_registry.md`

## 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.