---
tipo: cantiere
id: powerbricks
aliases: ["PowerBricks"]
nome: PowerBricks
fase: in costruzione (Fase 1 read-only)
output: visual query builder a mattoncini per colleghi non-tecnici
fonte: [strategia/Piano Lavoro PowerBricks, lavoro/AllRights BI Stream]
aggiornato: 2026-06-29
---
L'**asse primario** di lavoro (rev. 26/06, ha ribaltato l'agente NL come asse). Visual query builder Blockly → JSON → traduttore → SQL/DuckDB su Parquet; app desktop locale (PyWebView+Flask), read-only, **zero LLM**. È l'unica cosa che si mette in mano ai colleghi: 100% locale, niente governance/costo/errore silenzioso di un modello esterno.

Architettura "un asse, due teste sullo stesso layer": l'NL non scavalca PowerBricks, **lo genera** (testo → albero di blocchi ispezionabile → stesso traduttore validato). Il pezzo costoso — il **layer semantico** (4 aree: anagrafica, emesso, diritti, box office) — è condiviso; PowerBricks lo finanzia, l'NL ci si appoggia come asso coperto personale di Mauro (vedi [[NL query prototype]]).

Il cuore e il fossato: la **logica diritti** (titolarità %, passaggi consumati/residui, first-run vs re-run, inibizioni) è logica di business, non una JOIN — è dove stanno i mesi di lavoro di Bill, ed è perché PowerBricks batte qualsiasi tool generico (Tableau non sa cosa sia un passaggio residuo). Vale solo dentro Mediaset: fuori viaggia il pattern/CV, non il software.

Fase 2 (nodo architetturale): query → schedula → recapito email; introduce la scelta locale vs servizio (serve qualcosa di sempre acceso). Marcello ne ha visto solo il concetto generico ("rendere accessibile l'interrogazione ai colleghi"), non architettura/diritti/blocchi né il contatto col territorio [[AllRights]].

## Sinapsi
- eseguito_da :: [[Bill]] — i mesi di lavoro sul layer diritti
- poggia_su :: [[MyICR Suite]] — DuckDB/Parquet
- rischio :: [[AllRights]] — tensione-firma se PowerBricks attraversa il confine ICR verso quel territorio