# PowerBricks — tutto ciò che ho *Estratto dal vault, 13 luglio 2026. Fonte: nodo `powerbricks` + nodi collegati (`nl-query-prototype`, `myicr-suite`, `bill`, `allrights`).* > **Come leggere questo file.** Ogni affermazione porta la sua etichetta epistemica: > **fatto** = verificato · **fatto-riferito** = da documento · **lettura-Mauro** = tua posizione dichiarata · **inferenza-Elon** = mia, da verificare · **opzione** = ipotesi, non decisa. > Non è un piano di progetto. È lo stato di ciò che so — e una parte era sbagliata fino a oggi. --- ## 1. Stato reale **PowerBricks è un seme. Da circa cinque settimane. Tutto da progettare.** — *fatto (Mauro, 13/07/2026)* Non è in costruzione. Non è in Fase 1. Non esiste ancora codice. **Seme ≠ stallo.** — *fatto (Mauro, 13/07/2026)* È un progetto **ambizioso e non commissionato da nessuno**. Se si fa, si fa bene. Cinque settimane di seme non sono un rinvio: in quel periodo il lavoro è andato altrove. *"Asse primario" è un ordine di importanza, non di urgenza.* > ### Correzione — cosa diceva il vault fino al 13/07 > Il nodo dichiarava `fase: in costruzione (Fase 1 read-only)` e attribuiva a PowerBricks *"i mesi di lavoro di Bill"*. **Entrambe false.** (`invalidated_at`: 2026-07-13.) > *Inferenza-Elon da verificare:* quei mesi di lavoro sulla logica diritti esistono, ma stanno dentro **MyICR Suite / DataHub**, non dentro PowerBricks. > Nessuna query poteva accorgersene: sul mondo reale il vault non è una fonte verificabile, è un ricordo. È emerso solo perché te l'ho chiesto. --- ## 2. Che cos'è Un **visual query builder a mattoncini** per colleghi non tecnici. — *lettura-Mauro* **Catena:** frontend Blockly → JSON → traduttore Python → SQL su DuckDB/Parquet. **Involucro:** app desktop locale (contenitore **da decidere** — PyWebView, PyQt6+QtWebEngine o Flask nel browser), **read-only**, **zero LLM**. **Perché zero LLM è il punto, non un dettaglio:** è l'unica cosa che si può mettere in mano ai colleghi. 100% locale → niente governance, niente costo per query, niente errore silenzioso di un modello esterno su dati Mediaset. — *lettura-Mauro* --- ## 3. L'architettura: un asse, due teste sullo stesso layer Decisa nella revisione del **26/06/2026**, che ha ribaltato l'agente NL come asse portante. — *lettura-Mauro* - Il pezzo costoso — il **layer semantico** (4 domini: *anagrafica, emesso, diritti, box office*) — è il cuore di PowerBricks. **NL → blocchi** — fuori perimetro per **policy aziendale (divieto LLM)**. Non è PowerBricks e non si implementa. Eventualmente sarebbe qualcosa *on top* a PowerBricks, ma non nel perimetro attuale. **NL query prototype** — *fatto-riferito* Prototipo personale di Mauro (giugno 2026). **Non distribuibile** per policy aziendale. Resta separato da PowerBricks. --- ## 4. Il fossato: la logica diritti *(previsto, non costruito — lettura-Mauro)* La logica diritti **non è una JOIN: è logica di business.** - titolarità % - passaggi consumati / residui - first-run vs re-run - inibizioni È ciò che farebbe battere a PowerBricks qualsiasi tool generico: **Tableau non sa cosa sia un passaggio residuo.** **Confine da tenere presente:** vale dentro Mediaset. Fuori viaggia il **pattern** (e il CV), non il software. --- ## 5. Il layer semantico — specifica dell'08/07 *(fatto-riferito — documento `Progetto_PowerBricks_Specifiche`. È una specifica, non un'implementazione.)* L'utente **non vede JOIN né chiavi**. - Il backend risolve le relazioni cross-dominio via un **grafo delle relazioni hardcoded in Python**. - **LEFT JOIN sistematico con perno su Anagrafica** (dominio principale) — per non perdere entità non censite in un dominio. *Esempio: un film mai uscito al cinema è assente da Box Office, ma non deve sparire dal risultato.* - Flusso: Blockly → JSON `{campi_richiesti, filtri}` → traduttore Python → SQL standard, ottimizzato per SQLite / DuckDB-Parquet. - **Blocchi tipizzati** → errori di sintassi **impossibili per costruzione**: non si incastrano tipi incompatibili. --- ## 6. Fase 2 — *opzione, non decisa* Query → **schedulazione** → recapito via email. Introduce una scelta architetturale vera: **locale vs servizio**. Serve qualcosa di sempre acceso — e questo rompe il vincolo "100% locale" che oggi è il punto di forza del progetto. --- ## 7. Le fondamenta: MyICR Suite *(fatto)* PowerBricks **poggia su** MyICR Suite — la pipeline DuckDB/Parquet già operativa: - ~272.000 contratti di diritti - 8,7 milioni di emissioni storiche - 9 dataset su 34 reti - aggiornamento automatico, funziona offline, si installa copiando una cartella Ha sostituito Excel personali, macro VBA su Access e strumenti legacy. Include **MediaTrack** e **Linker**. **Il dato non è il problema. Il dato c'è.** Il problema è l'interrogabilità da parte di chi non scrive SQL. --- ## 8. Il territorio: AllRights *(fatto / inferenza-Elon dove indicato)* **Cos'è** — *fatto*: progetto BI commissionato da **CdG** (Controllo di Gestione), costruito da **Tecnologie** con consulenza GestioPerformance su **Qlik**. Oggetto: il ciclo di vita del diritto (acquisto → sfruttamento/emissione → rights out), con metriche economiche e quantitative. **Tenta di fare ciò che MyICR Suite già fa.** **Il suo limite** — *lettura-Mauro*: cruscotti Qlik fissi, nessuna cessione di controllo agli utenti, **nessuna AI nel perimetro**. Concezione pre-svolta. Atteso fallire sulle domande cross-dominio (anagrafica + emesso + diritti) — pattern già visto 15 anni fa su un Qlik analogo. *La sua inadeguatezza visibile sarà la prima occasione naturale per far valere il vantaggio.* **Il rischio su PowerBricks** — *inferenza-Elon*: tensione-firma se PowerBricks attraversa il confine ICR verso quel territorio. --- ## 9. Chi fa cosa — deciso il 13/07/2026 | Ruolo | Chi | Cosa | |---|---|---| | **Regia** | **Mauro** | Architettura, ribaltamento del 26/06, layer semantico. È già tua: non stai cercando un regista. | | **Progettazione tecnica** | **Mauro ↔ Bill**, diretto | *Genchi genbutsu*: si progetta dove sta la conoscenza del terreno (logica diritti, Parquet, DuckDB). Bill lo vede. | | **Esecuzione** | **Bill** | Non ancora avviata: non c'è cosa costruire. | | **Elon** | fuori da esecuzione e design tecnico | Non ho repo, ambiente, errori. Mettermi in mezzo = latenza + diagnosi su premesse parziali = *muda*. | | **Elon — dove serve** | perimetro e tempi | **Cosa entra nel perimetro e cosa no** (è una decisione). Più il **quando** e il **davanti a chi**: visibilità, tavoli, finestre. Bill questo non ce l'ha. | --- ## 10. Visibilità — chi sa cosa *(lettura-Mauro)* **Marcello** ha visto **solo il concetto generico**: *"rendere accessibile l'interrogazione ai colleghi"*. Non ha visto: l'architettura · la logica diritti · i blocchi · il contatto con il territorio AllRights. --- ## 11. Cosa non so — e che va deciso - **Il perimetro della v1.** Quali dei 4 domini entrano subito, e quali no. - **Dove si ferma la logica diritti nella prima versione.** È il fossato, ed è anche il pezzo più costoso: farla tutta subito è il modo più rapido per non finire mai. - **Se PowerBricks tocca AllRights, e quando.** È una decisione strategica, non tecnica. - **Cosa rende "fatto bene" questo progetto**, dato che nessuno te l'ha commissionato e quindi nessuno ti darà il criterio. Senza quel criterio, un progetto ambizioso non finisce: cresce. --- *Dossier generato da Elon il 13/07/2026 dal vault. Le parti marcate `inferenza-Elon` e `opzione` non sono fatti: sono mie o ipotesi aperte.*