---
type: modulo
parent: "Dropbox/adrian (sandbox)"
---

# CLAUDE.md — PowerBricks (sandbox prototipo)
**Versione:** v14
**Ultimo aggiornamento:** 2026-08-07

Eredita la Costituzione principale (`Dropbox/adrian/CLAUDE.md`). Solo contesto locale qui sotto.

## Cos'è

Prototipo del query builder visuale PowerBricks — passo 1 (solo Anagrafica) validato con
convinzione, ora in **passo 2** con l'aggiunta di Emesso (join + aggregazione), strategia
completa in `archivio/Mauro/lavoro/lavoro-python-ecosistema/PowerBricks.md`.

**Direzione strategica emersa 05/08/2026**: PowerBricks è di fatto un generatore di SQL
parametrico — l'output naturale non è solo una tabella HTML ma può alimentare **una griglia
in stile Linker** (MyICR_Suite), oggi in sola lettura. Vedi sezione "Griglia risultati PyQt6"
sotto per l'implementazione.

Vive fuori da `PYTHON/` deliberatamente: `PYTHON/` è scrivibile solo dall'istanza Ufficio,
questa sandbox invece va scritta anche da Nave. Sincronizzata via Dropbox+git come il resto
di `adrian/`.

## Stack

Stesso pattern di `PYTHON/MyICR_Suite/app/modules/mediatrack/` (modello di riferimento
dichiarato in MyICR_Suite/CLAUDE.md): **Flask + pywebview**, non browser puro — l'app si apre
come finestra desktop nativa, Flask gira in thread interno su `127.0.0.1`.

- **Flask** — unico backend, serve sia le pagine che l'API `/api/*`
- **pywebview** — finestra nativa che incapsula il frontend Flask
- **DuckDB** — query in-memory direttamente sul parquet Anagrafica, nessuna copia dati
- **Blockly** (via CDN nel frontend, vendorizzare se serve lavorare offline) — blocchi `pb_query` (contenitore Anagrafica), `pb_gruppo`/`pb_filtro` (filtri Anagrafica), `pb_emesso` (contenitore Emesso, indipendente), `pb_gruppo_emesso`/`pb_filtro_emesso` (filtri Emesso), `pb_join` (ponte facoltativo, forza il tipo di join — vedi sezione dedicata sotto)

Operatori supportati: `equals`, `not_equals`, `contains` (solo stringhe), `gt`/`lt`/`gte`/`lte` (solo numerici), `between` (numerici, valore `"v1,v2"`), `is_null`, `is_not_null`. Validazione lato backend per tipo di campo (`_build_filtro` in `backend/server.py`).

**Selezione campi in output — modale su doppio click (05/08/2026)**: dopo tre tentativi scartati per tenere la selezione sempre visibile (checkbox, doppio elenco fisso, blocco Blockly nativo), la soluzione finale tiene il canvas Blockly pulito (solo filtri) e sposta la scelta dei campi in un **modale HTML** che si apre con doppio click sul blocco `pb_query` ("Tabella Anagrafica") — un vero pannello dedicato che compare solo quando serve, coerente con come Access/Power BI trattano la selezione campi (vedi `PowerBricks.md`). Meccanica: estensione Blockly `pb_query_output_modal` (`Blockly.Extensions.register`, in `app.js`) aggancia un listener DOM `dblclick` su `block.getSvgRoot()`; il modale riusa il doppio elenco "disponibili ↔ selezionati" con frecce sposta/riordina; la selezione si salva su `block.data` (stringa JSON, serializzata automaticamente da Blockly col resto del workspace — nessuna persistenza custom necessaria).

## Passo 2 — Emesso (05/08/2026)

**Dati**: `emesso.parquet` (stesso `_PARQUET_DIR` di `prodotti.parquet`), 8,8M righe — molto
più grande di Anagrafica (226k), conferma la relazione **1:molti** anticipata nella strategia
(`PowerBricks.md`): un prodotto/edizione può avere decine/centinaia di righe, una per
trasmissione. Chiave di join: `prodotto`+`edizione`, stessa di Anagrafica. Campi esposti in
output (`EMESSO_FIELDS` in `backend/server.py`): `rete`, `data_emissione`, `ora_inizio`,
`ora_fine`, `durata_netta`, `prima_visione`, `episodio`, `audience`, `share`, `durata_lorda`,
`tipologia`, `fascia` — esclusi `prodotto`/`edizione` (chiavi di join, ridondanti in output) e
`ncparpgm` (codice interno, non utile).

**Emesso ora flessibile quanto Anagrafica (WHERE + SELECT), 05/08/2026**: dopo il primo giro
solo-aggregazione, richiesta esplicita di Mauro di rendere Emesso pari ad Anagrafica —
filtrabile con blocchi propri, non solo selezionabile in output. Aggiunti `pb_filtro_emesso`
e `pb_gruppo_emesso` (stessa logica di `pb_filtro`/`pb_gruppo`, stesso set operatori `OPS`,
campi presi da `ALL_EMESSO_FIELD_NAMES` invece di `ALL_FIELD_NAMES`), agganciati in un nuovo
slot `FILTRI` dentro `pb_emesso` stesso.

**Isolamento tra domini via `check` Blockly**: gli statement input e i blocchi dichiarano un
tipo di connessione (`anagrafica_filtro` per `pb_query`/`pb_filtro`/`pb_gruppo`,
`emesso_filtro` per `pb_emesso`/`pb_filtro_emesso`/`pb_gruppo_emesso`) — Blockly impedisce a
livello di incastro di mescolare un filtro Anagrafica dentro lo slot filtri di Emesso o
viceversa, non serve validarlo lato codice.

**`pb_query`/`pb_emesso` sganciati, blocchi indipendenti sulla lavagna (05/08/2026)**: prima
`pb_emesso` si agganciava in uno slot `EMESSO` dentro `pb_query` (nidificato). Corretto su
richiesta di Mauro: sono due blocchi container separati, entrambi senza
`previousStatement`/`nextStatement` (come `pb_query` già era) — viaggiano indipendenti sul
workspace, non uno dentro l'altro. Se `pb_emesso` è presente da qualche parte sulla lavagna,
si unisce **implicitamente** su `prodotto`+`edizione` (join fissa, nessuna scelta esplicita) —
Mauro ha segnalato esplicitamente che in futuro potrebbe arrivare un blocco "ponte" per
scegliere il tipo di join, ma non ora. Lato codice: `getEmessoConfig(workspace)` cerca il
blocco `pb_emesso` con `workspace.getBlocksByType("pb_emesso", false)` invece di leggerlo da
uno slot annidato di `pb_query` — il backend (join implicita su chiave fissa) non cambia,
solo la sorgente della configurazione lato frontend.

**Backend generico per tabella**: `_build_filtro`/`_build_node`/`_build_where` ora prendono
`fields_dict` e `table_alias` come parametri invece di essere hardcoded su `FIELDS`/`"a"` —
usati con `(FIELDS, "a")` per Anagrafica e `(EMESSO_FIELDS, None)` per Emesso (nessun alias
necessario dentro la subquery Emesso, un'unica tabella in scope lì). Aggiunto anche il tipo
`"float"` (per `share`) trattato come bucket numerico (`OPS_INT`) con cast `float()` invece di
`int()`.

**I filtri Emesso si applicano DENTRO la subquery**, prima di scegliere prima/ultima — "prima
emissione su rete X" deve restringere alle emissioni su X e poi prendere la più vecchia tra
quelle, non il contrario. Attenzione all'**ordine dei parametri SQL**: il JOIN (con gli
eventuali placeholder dei filtri Emesso) compare nel testo SQL prima della WHERE Anagrafica —
`_execute_query` passa `join_params + anagrafica_params` in quest'ordine a `con.execute()`.

Verificato su dati reali da Nave: filtro Emesso semplice, gruppo OR, campo `float` con
`between` — tutti sotto il secondo, nessuna regressione sulle query solo-Anagrafica.

**Blocco `pb_emesso`** ("Tabella Emesso"): contenitore indipendente sulla lavagna (vedi
sopra), opzionale — se assente, query solo su Anagrafica come nel passo 1.

**Aggregazione rimandata a uno step successivo (05/08/2026)**: inizialmente il blocco aveva
un dropdown `AGG` (prima/ultima/tutte le emissioni) integrato. Corretto su richiesta di
Mauro: "Tabella Emesso" deve restare un blocco che dichiara solo la tabella (nome coerente:
non più "Query Emesso — aggregazione..." ma "Tabella Emesso" secco) — l'aggregazione è un
concetto separato, un blocco a sé quando verrà implementato. **Oggi nessuna aggregazione nel
frontend**: il backend riceve `emesso` senza il campo `aggregation` e usa il default
`"tutte"` (una riga per emissione) — la logica prima/ultima via window function resta nel
backend (`_build_emesso_join`, invariata), pronta per quando un futuro blocco aggregazione la
richiamerà esplicitamente passando `"aggregation": "prima"|"ultima"`.

**LEFT JOIN di default, INNER se ci sono filtri Emesso (05/08/2026)**: gotcha reale trovato da
Mauro testando il prototipo — con LEFT JOIN sempre attiva, un filtro su Emesso (es.
`rete=I1`) non restringeva affatto i prodotti Anagrafica: i prodotti senza corrispondenza
uscivano comunque, solo con le colonne Emesso a `NULL`, perché LEFT JOIN mantiene le righe di
sinistra a prescindere dal match a destra. Un filtro sulla tabella joinata deve poter
significare "solo chi corrisponde", non "arricchisci se puoi". Fix in `_build_emesso_join`:
`join_type = "INNER JOIN" if emesso_clauses else "LEFT JOIN"` — con filtri Emesso presenti,
INNER (solo prodotti con un'emissione che soddisfa il criterio); senza filtri, resta LEFT
(Emesso arricchisce l'output senza restringere le righe Anagrafica, un prodotto senza
emissioni resta comunque visibile con colonne Emesso a `NULL`).

**Verificato su dati reali** (filtro `tipologia=FILM`): senza filtri Emesso, 471.494 righe
(52.215 con `emesso_rete` `NULL` — prodotti senza emissioni, LEFT corretto); con filtro
`rete=I1`, 30.690 righe, zero `NULL`, tutte effettivamente `I1` (INNER corretto).

**Compromesso risolto con un blocco "ponte" esplicito (05/08/2026)**: il caso "mostrami tutti
i prodotti, e se disponibile mostrami solo l'emissione su rete X" (LEFT JOIN + filtro solo
per la visualizzazione, non per restringere) non era esprimibile con la sola regola
automatica. Aggiunto `pb_join` — blocco indipendente, facoltativo, con una tendina
(`TYPE`): **Automatico** (la regola sopra: INNER se ci sono filtri Emesso, LEFT altrimenti),
**LEFT forzato** ("Tieni tutti gli Anagrafica"), **INNER forzato** ("Solo corrispondenze") —
sovrascrive la scelta automatica a prescindere dalla presenza di filtri. Colore neutro grigio
(`#757575`), coerente con la sua natura "ponte" tra domini, non appartiene a nessuna tabella
specifica.

Lato frontend: `getJoinType(workspace)` cerca `pb_join` con `getBlocksByType`, default
`"auto"` se assente — stesso pattern di `getEmessoConfig`. Lato backend:
`_parse_query_body` valida `join_type` (`auto`/`left`/`inner`, 400 se altro), 
`_build_emesso_join` lo usa per bypassare la regola automatica quando non è `"auto"`.

Verificato su dati reali tutti e tre i casi (`auto`+filtro → INNER 30.690 righe 0 NULL;
`left` forzato+filtro → LEFT 106.654 righe 75.964 NULL; `inner` forzato senza filtri →
419.279 righe 0 NULL) — i conteggi tornano esatti tra loro (es. `left`-`auto` = quanti
prodotti hanno emissioni ma non su quella rete).

Output Emesso selezionabile con lo stesso modale a doppio click di `pb_query` (generalizzato:
`openCampiModal(block, allNames)` ora prende l'elenco campi come parametro, non più
hardcoded su `ALL_FIELD_NAMES` — due estensioni Blockly separate, `pb_query_output_modal` e
`pb_emesso_output_modal`, stessa UI). Le colonne Emesso in output sono prefissate
`emesso_<campo>` (es. `emesso_rete`) per evitare collisioni con nomi di colonna già presenti
in Anagrafica (es. `tipologia` esiste in entrambe le tabelle).

**Gotcha backend risolto**: con la JOIN attiva, un nome di campo come `tipologia` esiste in
entrambe le tabelle — DuckDB solleva un errore di colonna ambigua se non prefissato. Tutti i
filtri Anagrafica (`_build_filtro`) ora usano il prefisso `a."campo"` esplicito (prima erano
senza prefisso, andava bene perché la tabella era una sola).

Verificato da Nave su dati reali: query con filtro Anagrafica + `prima`/`ultima`/`tutte` —
tutte sotto il secondo (window function su 8,8M righe non è un problema di performance con
DuckDB). Validazione errori confermata (aggregazione non valida → 400, campo Emesso non
valido → 400). **Non ancora testato visivamente** su un display reale (Ufficio).

## Griglia risultati — migrata da PyQt6 a datagrid web (07/08/2026)

`[CONFERMATO]` — sostituisce interamente la sezione "Griglia risultati PyQt6" sotto (lasciata
per lo storico tecnico dei bug risolti, ma **non più il flusso attivo**). Nata da una
riflessione più ampia su tutta la griglia risultati stile Linker (visualizzazione, il
gestionale/data-entry resta fuori scope) — dettaglio completo della valutazione PyQt6 vs web e
la scelta di Tabulator vs AG Grid in `archivio/Mauro/lavoro/lavoro-python-ecosistema/
PowerBricks.md`.

**Componente**: [[datagrid]] (`sandbox/datagrid/`) — libreria riusabile standalone, non
specifica di PowerBricks. Motivo esplicito di Mauro: la griglia è un candidato a diventare il
componente condiviso per tutto MyICR (dove oggi vive la griglia Linker storica), non uno
strumento usa-e-getta di questo prototipo.

**Meccanica**: il vincolo "pywebview e PyQt6 non condividono lo stesso loop eventi" (motivo per
cui la vecchia griglia girava come `subprocess.Popen` separato) **non si applica più** — il
componente è puro JS, quindi i risultati si aprono in una **seconda finestra pywebview**
(`webview.create_window`, stesso processo, nessun conflitto), non un processo a sé. Flusso:
"Esegui query" → POST `/api/open_grid` (invariato lato frontend `app.js`) → il backend esegue
la query, salva `{columns, rows}` in `_RESULTS_STORE` (dict in memoria, cap 20 con eviction
FIFO — nessuna persistenza, un token vale finché il processo Flask resta vivo) sotto un token
`uuid4`, poi chiama `webview.create_window(titolo, "http://127.0.0.1:5050/results.html?token=...",
width=1100, height=700)`. `results.html` (nuovo, `frontend/`) legge il token dalla query
string, fa `fetch('/api/results/<token>')`, converte `{columns, rows}` (liste, stesso formato
di `/api/query`) in oggetti riga per Tabulator, e inferisce il tipo colonna (`number`/`text`)
guardando il primo valore non nullo di ogni colonna — euristica semplice, non lo schema tipato
vero (`FIELDS`/`EMESSO_FIELDS`/...): sufficiente per sort/filtro di base, potrà affinarsi se
servirà (es. quando arriverà il concetto di "cluster"/preset di campi, vedi `PowerBricks.md`).

**Il componente datagrid non è copiato**: servito via una seconda static route Flask
(`/vendor/datagrid/<path:filename>` → `sandbox/datagrid/src/`) — un solo sorgente di verità,
PowerBricks lo consuma via URL come un consumer esterno qualunque.

**Rimosso in questo giro**: `results_grid.py` (script PyQt6 standalone), dipendenza
`PyQt6==6.7.0` da `requirements.txt`, `RESULTS_GRID_SCRIPT`/`subprocess`/`tempfile` da
`backend/server.py`. `HOST`/`PORT` spostate da `run.py` a `backend/server.py` (servono anche
lì per costruire l'URL della finestra risultati) — `run.py` ora le importa invece di
duplicarle.

**Griglia deliberatamente read-only per ora**: stessa scelta della vecchia PyQt6 (coerente con
Linker in sola lettura) — il componente `datagrid` supporta editing di cella nativamente, ma
`editable` non è passato in `results.html`. Riflette lo scope esplicito di Mauro
(07/08/2026): solo visualizzazione, il gestionale/data-entry resta un capitolo a sé,
volutamente rimandato.

Verificato da Nave: `test_client()` per `/api/open_grid` (con `webview.create_window` mockato
— chiamato con l'URL/token/dimensioni attesi), `/api/results/<token>` (200 con dati, 404 su
token inesistente), `/vendor/datagrid/datagrid.js` (200). `results.html` verificato con
Playwright headless contro un server Flask reale con risultati precaricati: rendering righe,
gestione token invalido (messaggio esplicito, nessun crash). **Non ancora verificata
l'apertura reale della seconda finestra pywebview** (serve un display reale, headless non
esercita `webview.start()`/`create_window` davvero) — prossimo test da fare su Ufficio.

## Campi derivati Anagrafica (IMDB/regista/attori) + label leggibili (07/08/2026)

`[CONFERMATO]` — nato dalla replica del cluster Anagrafica di Linker (14 campi a intestazione
arancione in `column_defs.py`, confermati da Mauro con screenshot reale). 11 dei 14 erano già
in `FIELDS`; mancavano `IMDB`, `REGISTA`, `ATTORI`.

**Decisione presa con Mauro**: niente nuova "Tabella Cast" standalone — `cast.parquet` ha una
relazione 1:molti pesante con `prodotto` (fino a 1.369 righe, tutti i ruoli), esporlo come
dominio a sé avrebbe richiesto la stessa complessità di aggregazione di Emesso/Diritti senza
un bisogno reale: a Linker non serve la lista cast grezza, solo un riassunto già a 1 riga per
prodotto. Aggiunti invece **tre campi derivati dentro Anagrafica stessa**
(`imdb_codice`/`regista`/`attori`), stessa logica di `v_custom_anagr` in Linker
(`PYTHON/MyICR_Suite/app/modules/linker/src/database/parquet_db.py:40-108`), riletta 1:1 non
reinventata: `imdb_codice` da un LEFT JOIN univoco su `imdb.parquet.codice` (verificato: 110.773
righe = 110.773, nessun fan-out); `regista` dal primo `cast.parquet` con `ruolo='FRE'` ordinato
per `progr_cast` (`QUALIFY ROW_NUMBER() ... = 1`); `attori` dai primi 3 `ruolo='C001'`
concatenati (`STRING_AGG` ordinato per `progr_cast`). Implementato in `_anagrafica_base_sql()`
(`backend/server.py`), sostituisce il semplice `read_parquet(prodotti)` come FROM base di
`_execute_query` — nessuna deduplicazione per "prodotto" a differenza di Linker (PowerBricks
tiene il grano prodotto+edizione intero, i tre derivati si ripetono identici su tutte le
edizioni dello stesso prodotto, nessun problema perché sono già aggregati a monte).

**Idea per il futuro, annotata non implementata**: REGISTA/ATTORI sono di fatto "cluster
calcolati" (riassunto di più righe cast) — un domani potrebbero fare drill verso il dettaglio
cast grezzo filtrato per ruolo. Non affrontato ora, solo segnato perché non vada perso.

**Label leggibili stile Linker** (stesso giro, richiesta di Mauro: "decodificare i nomi campo
come in Linker, nelle tendine e nella griglia"): `ANAGRAFICA_LABELS`/`EMESSO_LABELS`/
`BOXOFFICE_LABELS`/`DIRITTI_LABELS` in `backend/server.py`, mappano il nome campo grezzo alla
label `column_defs.py` di Linker **solo dove la corrispondenza è certa** — es. `titolo_italiano`
→ `TI`, `ragsoc_distr` → `DISTRIBUTORE`, `data_debutto` → `DEBUTTO`. **Gemma esclusa
deliberatamente** (`GEMMA_LABELS = {}`): le valutazioni `VAL_*` di Linker non hanno una
corrispondenza inequivocabile con i campi `v_*`/`a_*` esposti qui senza verificare il codice che
le costruisce — meglio nessuna label che una indovinata male. Ogni `/api/fields*` ora restituisce
anche `"label"` (fallback al nome se assente dal dizionario). Nuovo endpoint `/api/labels`
(dizionario piatto, chiavi = nomi colonna **in output**, quindi con prefisso dominio per i
satelliti — es. `emesso_rete` → `RETE`) usato da `results.html` per le intestazioni di colonna
della griglia. Frontend (`app.js`): `FIELD_LABELS` (dizionario globale nome→label, popolato da
`/api/fields*` in `main()`) usato sia nelle tendine `FIELD` dei blocchi filtro sia nel modale di
selezione output — fallback al nome grezzo se non mappato.

Verificato su dati reali da Nave: query diretta su un prodotto dello screenshot condiviso da
Mauro (3096645, "LIFE OF THE PARTY") — output esatto `imdb_codice='tt5619332'`,
`regista='BEN FALCONE'`, `attori='MELISSA MCCARTHY, MATT WALSH, MOLLY GORDON'`, identico a
Linker. `test_client()` per `/api/fields`/`/api/labels`. Playwright headless: tendina `FIELD`
mostra `RIFER=prodotto`/`TI=titolo_italiano` (label mappate) e `edizione=edizione` (fallback
per campi non mappati); intestazioni griglia risultati `RIFER, TI, IMDB, REGISTA, ATTORI` per
una query con quei campi in output. **Non ancora verificato visivamente** su Ufficio.

## Default output Anagrafica = cluster Linker (07/08/2026)

`[CONFERMATO]` — richiesta di Mauro: un blocco "Tabella Anagrafica" mai toccato nel modale
selezione campi deve avere come default il cluster Linker (14 campi, stesso ordine), non
"tutti i campi" come prima. `ANAGRAFICA_DEFAULT_FIELDS` in `app.js` (stesso ordine di
`column_defs.py`). `getBlockOutputFields(block, allNames, defaultFields)` e `openCampiModal`
accettano ora un terzo parametro opzionale `defaultFields` — se assente (Emesso/Boxoffice/
Diritti/Gemma, nessun cluster deciso per loro ancora) il comportamento resta invariato
("tutti i campi"). Il default si applica sia al modale (campi già preselezionati in
"selezionati") sia a `getQueryPayload` (i campi effettivamente mandati al backend se il
blocco non è mai stato aperto). Verificato con Playwright: workspace con solo il blocco
`pb_query` di partenza (mai toccato) → `getQueryPayload(...).fields` produce esattamente i
14 campi nell'ordine atteso.

## Persistenza workspace Blockly (07/08/2026)

`[CONFERMATO]` — richiesta di Mauro: non dover ricostruire la query manualmente ad ogni test.
Autosave debounced (500ms, `workspace.addChangeListener`, stesso pattern del pannello
pseudo-lingua) verso `POST /api/workspace`, che scrive `Blockly.serialization.workspaces.save(workspace)`
su file locale (`.workspace_state.json`, root della sandbox, **mai in git** — dato di sessione,
non sorgente, aggiunto a `.gitignore`). All'avvio, `GET /api/workspace` prova a ripristinare
l'ultimo stato salvato (`Blockly.serialization.workspaces.load`); se assente (primo avvio, o
file mai scritto), fallback al solito blocco "Tabella Anagrafica" di partenza.

**Scelta deliberata: autosave ad ogni modifica, non salvataggio-su-chiusura**: Mauro ha chiesto
"quando esco dall'applicativo mi salvi i blocchi" — implementato però come autosave continuo
(debounced) invece di agganciarsi all'evento di chiusura pywebview: più semplice (nessun hook
sul ciclo di vita della finestra) e più robusto (nessun rischio di perdere lo stato se l'app si
chiude in modo brusco, crash o kill del processo — un salvataggio-su-chiusura per definizione
non protegge da quel caso).

Verificato con Playwright: file assente → `GET /api/workspace` restituisce `null` → workspace
parte vuoto (blocco di partenza standard); aggiunto un blocco `pb_boxoffice` via API Blockly,
atteso il debounce, contati i blocchi (2) → reload pagina → blocchi ancora 2, `pb_boxoffice`
presente — stato ripristinato correttamente. File JSON ispezionato, contiene le posizioni e i
tipi di blocco attesi.

## Griglia risultati — replica stile Linker (07/08/2026)

`[CONFERMATO]` — richiesta esplicita di Mauro: "replicare quanto più possibile il layout del
foglio Linker, stessi caratteri, stessi colori intestazioni". Il tema di base (font, riga
compatta, cella selezionata Excel-style) vive nel componente condiviso `sandbox/datagrid/`
(vedi `sandbox/datagrid/CLAUDE.md`, non duplicato qui). Quello che è specifico di PowerBricks è
solo la **mappatura colore-header per dominio**, in `frontend/results.html`
(`headerColorFor(name)`), stessa palette `HC` di
`PYTHON/MyICR_Suite/app/modules/linker/src/gui/column_defs.py`:

| Dominio (prefisso colonna output) | Colore | Hex |
|---|---|---|
| Anagrafica (nessun prefisso) | arancione | `#FFB347` |
| `imdb_codice` (caso speciale) | ciano | `#00BFFF` |
| `emesso_*` | arancione (Linker: "generaliste") | `#FFB347` |
| `boxoffice_*` | giallo | `#FFFF00` |
| `diritti_*` | verde | `#90EE90` |
| `gemma_*` | giallo pastello (Linker: "Valutazioni") | `#FFF59D` |

A differenza di Linker, ogni dominio qui copre l'intera tabella (nessuna colonna "non
classificata" — Linker mostra solo un sottoinsieme curato per dominio, PowerBricks espone
tutti i campi disponibili quindi tutti condividono il colore del loro dominio). Nessuna
distinzione "Emesso tematiche" (viola in Linker): PowerBricks ha un solo dominio Emesso, non
lo split generaliste/tematiche.

Verificato con Playwright: colori header confrontati byte-per-byte coi valori RGB attesi su una
query con 4 domini contemporanei (Anagrafica+IMDB, Boxoffice, Diritti), font Calibri applicato,
altezza filtri header allineata alle righe dati (corretto dopo un primo giro troppo alto).
**Non ancora verificato visivamente** su Ufficio.

**Bug reale trovato e corretto (07/08/2026) — scrollbar verticale spuria**: presente anche con
poche righe che non riempivano la pagina, segnalato da Mauro. Causa: non la griglia stessa
(Tabulator gestisce correttamente il proprio scroll interno), ma la **pagina** attorno —
`calc(100vh - 40px)` più i margini di `#status`/`#grid` superava di pochi pixel l'altezza del
viewport (misurato: 705px di contenuto contro 700px disponibili), abbastanza per far comparire
lo scroll del documento. Fix: `html, body { overflow: hidden }` — la griglia resta l'unica area
scrollabile (verificato: con 100 righe lo scroll interno funziona regolarmente, 2244px di
contenuto contro 612px visibili).

**Intestazioni colonna centrate** (07/08/2026, richiesta di Mauro): `text-align: center` su
`.tabulator-col-title`, nel tema di base del componente `datagrid` (non specifico di
PowerBricks — beneficia chiunque altro lo consumi).

**Colonne a larghezza fissa, stesso valore esatto di Linker (07/08/2026)**: di default il
componente `datagrid` dimensiona le colonne sul contenuto (`fitDataFill`, prima
`fitDataStretch` — cambiato perché allungava comunque l'ultima colonna, contraddicendo l'idea
di "fisse") — Mauro ha chiesto di renderle fisse. Stesso principio delle label: nuovi
dizionari `ANAGRAFICA_WIDTHS`/`EMESSO_WIDTHS`/`BOXOFFICE_WIDTHS`/`DIRITTI_WIDTHS` in
`backend/server.py` (px esatti da `column_defs.py`, es. `titolo_italiano` → 200, `prodotto` →
61), `GEMMA_WIDTHS = {}` (stesso motivo di `GEMMA_LABELS`: nessuna corrispondenza certa).
Nuovo endpoint `/api/widths` (stesso pattern prefisso-dominio di `/api/labels`), usato da
`results.html` con fallback a 100px per i campi senza un valore Linker noto. Verificato con
Playwright: 14 colonne del cluster Anagrafica, larghezze in pixel confrontate una per una coi
valori attesi — corrispondenza esatta.

## Griglia risultati PyQt6 (05/08/2026)

**Perché un processo separato**: `pywebview` (finestra Blockly) e PyQt6 sono due toolkit GUI
diversi, ognuno col proprio loop eventi — non possono coesistere nello stesso processo senza
conflitti. Soluzione: `results_grid.py` (root della sandbox, sibling di `backend/`/`frontend/`)
è uno script PyQt6 standalone, lanciato come **sottoprocesso** (`subprocess.Popen`) dal
backend Flask.

**Flusso (semplificato 05/08/2026)**: il pulsante è uno solo, **"Esegui query"** → POST
`/api/open_grid` direttamente (niente tabella HTML intermedia, niente pulsante separato
"Apri in griglia" — rimossi su richiesta esplicita: il risultato vive solo nella griglia
PyQt6, non nella finestra del query builder) → il backend esegue la query, scrive
`{columns, rows}` in un file JSON temporaneo (`tempfile.NamedTemporaryFile`), lancia
`subprocess.Popen([sys.executable, results_grid.py, tmp_path])` e risponde subito (non
aspetta la chiusura della finestra). `results_grid.py` legge il JSON, lo cancella
(`unlink()`), poi apre una `QTableWidget` read-only (`NoEditTriggers`) — editing eventuale
solo in futuro, oggi è deliberatamente sola lettura come Linker.

`/api/query` resta nel backend (limite 1000, usato dai test rapidi da terminale/`test_client`)
ma non è più chiamato dal frontend — solo `/api/open_grid` (limite 5000) è nel percorso reale.

**Refactor backend**: `_parse_query_body()`/`_execute_query()` estratte da `/api/query` e
condivise con `/api/open_grid` — stessa validazione, stesso motore DuckDB, limite massimo
diverso per endpoint.

Dipendenza `PyQt6==6.7.0` (pin standard di casa) in `requirements.txt`. Verificato da Nave con
`QT_QPA_PLATFORM=offscreen` (headless, nessun display) — costruzione finestra/tabella
corretta, file temporaneo pulito correttamente prima di entrare nel loop eventi Qt. **Non
ancora verificato visivamente** (serve un display reale, Ufficio).

**`results_grid.py` resta volutamente semplice, nessuno stile custom**: un primo tentativo
aveva applicato la palette MediaTrack (QSS + `app.setStyle("Fusion")`, necessario perché lo
stile nativo Windows ignora parzialmente i QSS su `QHeaderView`) proprio a questo foglio — poi
corretto: la richiesta era vestire il **query builder**, non il foglio risultati, che va
lasciato semplice. Non applicare styling qui senza indicazione esplicita.

## Toolbox a categorie per dominio (06/08/2026)

`[CONFERMATO]` — Mauro ha notato guardando lo screenshot col pattern "due domini attivi" che
il toolbox flat (tutti i blocchi di tutti i domini sempre visibili in un unico elenco) non
avrebbe retto con Diritti/Boxoffice aggiunti (4 domini × ~3 blocchi = affollamento). Discusse
insieme alcune opzioni (categorie collassabili, due pannelli custom sincronizzati
tabella↔blocchi) prima di convergere su una soluzione nativa: il **category toolbox** di
Blockly (lo stesso pattern di "Logic/Loops/Math" nei playground ufficiali) è già di fatto un
sistema a due pannelli — elenco categorie stretto a sinistra, flyout a comparsa coi blocchi
della categoria selezionata — senza bisogno di codice custom per sincronizzare stato tra due
pannelli.

**Implementato**: `frontend/index.html`, toolbox XML convertito da `<block>` flat a
`<category>` per dominio — "Anagrafica" (`#C62828`), "Emesso" (`#F9A825`), "Strumenti"
(`#757575`, oggi solo `pb_join`) — stessi colori già in uso per i blocchi. Quando arriveranno
Diritti/Boxoffice, bastano due categorie in più con lo stesso pattern.

**Bottoni nel flyout invece di solo blocchi trascinabili**: Blockly supporta elementi
`<button text="..." callbackKey="...">` dentro una categoria XML, con
`workspace.registerButtonCallback(key, fn)` lato JS — usato per aggiungere "Seleziona campi
output..." nel flyout di Anagrafica/Emesso, che apre la stessa modale del doppio click sul
blocco (vedi sopra) ma senza richiedere di sapere che il doppio click esiste. Se il blocco
"Tabella" non è ancora sulla lavagna, `getOrCreateTableBlock()` lo crea al volo prima di
aprire il modale (stessa logica del blocco di partenza creato all'avvio). Il doppio click
resta come scorciatoia alternativa, non rimosso.

**Non ancora testato visivamente** su Ufficio (fatto da Nave, headless — solo verifica
sintattica JS). Prossimo giro di test reale dovrà controllare che le categorie/bottoni si
comportino come atteso a schermo.

## Terzo dominio — Boxoffice (06/08/2026)

`[CONFERMATO]` — Mauro ha chiesto di aggiungere Boxoffice ("è semplice"), tornando sulla
decisione di `PowerBricks.md` che lo scartava per il passo 2 a favore di Emesso (motivazione
originale: tabella marginale nel lavoro ICR reale). Non un ripensamento strategico registrato
altrove — solo la constatazione, confermata sui dati, che tecnicamente è il dominio più
semplice fin qui: **relazione 1:1 su `prodotto`** (verificato: 39.771 righe = 39.771 prodotti
distinti in `boxoffice.parquet`, nessun duplicato), quindi nessuna window function, nessuna
scelta di aggregazione prima/ultima/tutte come per Emesso — un JOIN diretto basta e la
cardinalità del risultato non cambia mai.

**Dati**: `boxoffice.parquet` (stesso `_PARQUET_DIR`), colonne `prodotto` (chiave di join,
esclusa dall'output), `stagione`, `data_debutto`, `distributore`, `incasso`, `spettatori`.
`data_debutto` è `DATE` nel parquet — **castato a `VARCHAR`** nella subquery
(`_build_boxoffice_join`), necessario sia per confrontarlo nei filtri come stringa (coerente
con `data_emissione` di Emesso, già `VARCHAR`) sia perché `jsonify` non serializza
`datetime.date` nativamente — senza il cast l'endpoint avrebbe restituito un 500 silenzioso
alla prima query con quel campo in output.

**Stessa regola automatica LEFT/INNER di Emesso**: con filtri Boxoffice presenti, INNER (un
prodotto senza corrispondenza esce dal risultato); senza filtri, LEFT (Boxoffice arricchisce
senza restringere). Blocco ponte facoltativo `pb_join_boxoffice` ("Join Anagrafica ↔
Boxoffice") per forzare la scelta, stesso pattern/tendina di `pb_join` — non riusato lo stesso
blocco per i due domini: ogni ponte è specifico alla coppia che collega, stessa scelta già
presa per `pb_filtro`/`pb_gruppo` duplicati invece di un blocco generico (vedi sezione Passo
2 sopra, "Spunto valutato e accantonato").

**Frontend**: blocchi `pb_boxoffice` (container "Tabella Boxoffice"), `pb_filtro_boxoffice`/
`pb_gruppo_boxoffice` (stesso pattern Anagrafica/Emesso, check `boxoffice_filtro` per
isolamento via incastro Blockly), estensione `pb_boxoffice_output_modal` (stesso modale a
doppio click, generalizzato). Famiglia colore verde (Material Green: primario `#2E7D32`,
medio `#66BB6A`, chiaro `#A5D6A7`) — terza famiglia dopo rosso Anagrafica/ambra Emesso,
coerente con la decisione "colore per dominio" del 05/08. Categoria "Boxoffice" propria nel
toolbox (vedi sezione sopra sulle categorie), con lo stesso bottone "Seleziona campi
output..." nel flyout.

**Backend generalizzato per più join contemporanee**: `_execute_query` ora accetta sia
`emesso` che `boxoffice` e concatena i rispettivi `JOIN` nell'SQL (Emesso prima, Boxoffice
dopo — stesso ordine dei parametri passati a `con.execute()`). Verificato che le due join
possono coesistere nella stessa query senza collisioni di alias (`e` per Emesso, `bo` per
Boxoffice) né di nomi colonna in output (prefisso `boxoffice_<campo>`, stesso schema di
`emesso_<campo>`).

Verificato su dati reali da Nave: filtri stringa/numerici su Boxoffice, LEFT vs INNER (con
filtro `incasso > 1.000.000`: solo prodotti con un incasso registrato sopra soglia), query
combinata Anagrafica+Emesso+Boxoffice nella stessa richiesta. **Non ancora testato
visivamente** su Ufficio.

## Quarto dominio — Diritti, solo campi grezzi (06/08/2026)

`[CONFERMATO]` — a differenza di Emesso/Boxoffice, la specifica ufficiale
(`PowerBricks_Specifiche.md` §4) segnala esplicitamente che Diritti **non è esprimibile come
semplice JOIN**: titolarità %, passaggi consumati/residui, first-run/re-run e inibizioni sono
logica di business derivata, non chiavi relazionali — "il cuore del valore" del prodotto,
dove si concentra la maggior parte dello sforzo previsto. Coerente con la strategia
"prototipo minimo" già usata per Emesso/Boxoffice (partire semplice, validare, poi
stratificare), questo primo giro espone **solo i campi grezzi del contratto**, con un JOIN
diretto (nessuna logica derivata) — la logica di business resta un layer a sé, deliberatamente
rimandato.

**Dati**: `diritti.parquet` (stesso `_PARQUET_DIR`, 51.402 righe), chiavi di join `prod`/`ediz`
— nomi diversi da `prodotto`/`edizione` di Anagrafica (a differenza di Emesso/Boxoffice che
condividono già la stessa nomenclatura), quindi `ON a."prodotto" = d."prod" AND a."edizione" =
d."ediz"` esplicito in `_build_diritti_join`. **Relazione 1:molti verificata sui dati**: 51.402
righe / 31.157 coppie `prod`+`ediz` distinte, fino a 25 righe diritto per lo stesso
prodotto/edizione (contratti/decreti diversi nel tempo) — stessa natura di Emesso, ma **senza
aggregazione prima/ultima/tutte** in questo giro: il backend restituisce sempre tutte le righe
diritto che soddisfano i filtri (equivalente al "tutte" di Emesso), la scelta di
un'eventuale aggregazione è rimandata insieme al resto della logica derivata.

**Campi esposti** (18, tutti "grezzi"): `tipologia`, `d_t`, `ragsoc_distr`, `perc`,
`pass_cons`, `pass_cons_tot`, `pass_eff`, `pass_eff_tot`, `decr`, `scad`, `causale`,
`flag_inib`, `decr_inib`, `scad_inib`, `contratto`, `riga`, `situazione`, `fr_rr`. **Esclusi
deliberatamente**: `id_diritto`/`prod`/`ediz` (chiavi tecniche/di join) e le 45 colonne
`CONTRAENTE_WIN_1..9`/`DECR_WIN_1..9`/`SCAD_WIN_1..9`/`CAUSALE_WIN_1..9`/
`CAUSALE_INIBIZIONE_WIN_1..9`/`NOTE_WIN_1..9` — nove finestre storiche per riga che sono
proprio il materiale grezzo della logica derivata (first-run/re-run, inibizioni) rimandata
sopra, non semplici campi filtrabili. `decr`/`scad`/`decr_inib`/`scad_inib` sono `DATE` nel
parquet — stesso trattamento di `data_debutto` (Boxoffice): **cast a `VARCHAR`** nella
subquery di join, sia per coerenza dei filtri stringa sia perché `jsonify` non serializza
`datetime.date`.

**`diritti_enrich.parquet` agganciata come tabella "sidecar" trasparente (06/08/2026, stesso
giro)**: su richiesta di Mauro, i due campi di `diritti_enrich.parquet` (`fornitore_cluster`,
`ESCLUSIVO_TEM` — verificato relazione **1:1 su `id_diritto`**, 51.402 righe = 51.402, zero
orfane in entrambe le direzioni) sono esposti **come se fossero già parte di `diritti.parquet`**
— stesso blocco "Tabella Diritti", nessun blocco/dominio separato. Meccanica: `_build_diritti_join`
fa un `LEFT JOIN` interno tra `diritti.parquet` e `diritti_enrich.parquet` su `id_diritto`
dentro la stessa subquery, prima ancora di applicare i filtri utente — l'utente non vede mai
la seconda tabella, solo due campi in più (`fornitore_cluster`, `esclusivo_tem`, nome in
minuscolo per coerenza con gli altri 18) nel modale di selezione output e nella tendina
filtri. `ESCLUSIVO_TEM` è `BOOLEAN` nel parquet — esposto come stringa (`"true"`/`"false"`,
**cast** nella subquery) per restare nel sistema di filtri generico esistente (`OPS_STRING`/
`OPS_INT`) senza introdurre un tipo "bool" per un solo campo — costo/beneficio non
giustificato per due valori possibili. Ora 20 campi totali per Diritti.

**Stessa regola automatica LEFT/INNER di Emesso/Boxoffice**: con filtri Diritti presenti,
INNER; senza, LEFT. Blocco ponte facoltativo `pb_join_diritti` ("Join Anagrafica ↔ Diritti"),
stesso pattern/tendina degli altri due ponti — non riusato un blocco generico, stessa scelta
già presa per gli altri domini.

**Frontend**: blocchi `pb_diritti` (container "Tabella Diritti"), `pb_filtro_diritti`/
`pb_gruppo_diritti` (check `diritti_filtro` per isolamento via incastro Blockly), estensione
`pb_diritti_output_modal` (stesso modale a doppio click). Famiglia colore blu (Material Blue:
primario `#1565C0`, medio `#42A5F5`, chiaro `#90CAF9`) — quarta famiglia dopo rosso/ambra/
verde. Categoria "Diritti" propria nel toolbox, stesso bottone "Seleziona campi output...".

**Bug reale trovato da Mauro testando su Ufficio (06/08/2026) — tipo "date" mancante, corretto
per tutti e tre i domini con campi data**: filtrare `decr` con `gte` falliva ("operatore non
valido per decr: gte") — `decr`/`scad`/`decr_inib`/`scad_inib` erano tipizzati `"string"`
(per via del cast a VARCHAR in output), che nel motore filtri abilita solo
`equals`/`contains`/`is_null` (`OPS_STRING`), non i confronti (`gt`/`lt`/`gte`/`lte`/
`between`) — proprio gli operatori più utili per date di decorrenza/scadenza. **Stesso bug
verificato presente anche** su `data_emissione` (Emesso) e `data_debutto` (Boxoffice, entrambi
già in produzione da giorni prima che qualcuno provasse un confronto invece di un'uguaglianza)
— non specifico di Diritti, un difetto di design nel riuso di `"string"` per colonne che sono
davvero date. **Fix**: nuovo tipo `"date"`, con `OPS_DATE` = unione di `OPS_STRING` e
`OPS_INT` (comprende sia `contiene` — utile per "contiene 2026" senza scrivere una data
completa — sia i confronti). `_parse_date_value()` converte il formato italiano `GG/MM/AAAA`
digitato dall'utente nel formato ISO `YYYY-MM-DD` della colonna (già castata a VARCHAR in
output) — necessario perché il confronto è lessicografico sulla stringa, corretto solo se
entrambi i lati sono nello stesso formato ISO. **Un secondo bug scoperto testando il fix**:
per `contains` su un campo `"date"`, il filtro nel `WHERE` agisce sulla colonna **grezza** del
parquet sorgente (spesso ancora `DATE`, non VARCHAR — il `CAST` esiste solo nella `SELECT` a
valle, non visibile nel `WHERE` della stessa query) — `ILIKE` non fa cast implicito
DATE→VARCHAR come invece fanno gli operatori di confronto (che DuckDB gestisce con un cast
implicito silenzioso), quindi serve un `CAST` esplicito dentro il frammento WHERE stesso solo
per questo operatore. Nessuna modifica frontend necessaria: la tendina operatori nei blocchi è
già generica per tutti i campi, il backend si limita a validare/rifiutare le combinazioni non
valide. Verificato con `test_client()` su tutti gli operatori × tutti e tre i domini, più
verifica di non regressione sui campi string/int/float esistenti.

**Bug preesistente trovato e corretto nello stesso giro**: il pannello pseudo-lingua
(`blockToNode` in `app.js`) riconosceva solo i tipi di blocco Anagrafica/Emesso
(`pb_filtro`/`pb_filtro_emesso`, `pb_gruppo`/`pb_gruppo_emesso`) — i filtri Boxoffice
(aggiunti nel giro precedente) non comparivano mai nell'anteprima testuale pur funzionando
correttamente nella query vera (percorso di codice separato, `getQueryPayload`). Corretto
generalizzando a liste `FILTRO_BLOCK_TYPES`/`GRUPPO_BLOCK_TYPES` che includono ora tutti e
quattro i domini.

Verificato su dati reali da Nave: query SQL diretta (conteggio prodotti distinti LEFT vs
INNER, 79.665 invariati vs 15.110 con filtro `situazione=1`), poi via `test_client()`
(join/filtri/validazione campo), poi end-to-end con `playwright` headless (blocchi via API
Blockly diretta, pannello pseudo-lingua, query reale contro `/api/query`) — stesso metodo già
usato per validare il pannello pseudo-lingua. **Non ancora testato visivamente** su Ufficio.

## Quinto dominio — Gemma, join tramite IMDb (06/08/2026)

`[CONFERMATO]` — dataset di tracking acquisizioni/screener (non da OnAir come gli altri
parquet, fonte diversa), livello "pre-prodotto": la maggior parte delle righe non è ancora
(o non sarà mai) un prodotto Mediaset anagrafato. 58 colonne, tutte `VARCHAR`, due prefissi:
`A_*` (dati di acquisizione: titolo, distributore, autore/regista, cast, deadline...) e `V_*`
(valutazione per rete: C5, I1, R4, LA5, IRIS, ecc.).

**Join su richiesta esplicita di Mauro: tramite codice IMDb, non tramite `A_CODICE_PRODOTTO`**
(che pure esiste in Gemma, ma valorizzato solo sul 9,5% delle righe — 4.931/51.975). Gemma non
ha `prodotto`/`edizione` propri: il percorso è `gemma.A_COD_IMDB` → `imdb.riferimento_imdb` →
`imdb.codice` = `prodotti.prodotto` (`imdb.parquet` fa già da tabella ponte per altri scopi,
qui riusata solo per risolvere questo join — non è un dominio/blocco a sé).

**Fan-out reale, verificato e accettato**: `imdb.riferimento_imdb` **non è univoco** — uno
stesso ID IMDb può corrispondere a più `codice` interni (fino a 41 osservati), quindi il join
a catena produce più righe del semplice match diretto gemma↔imdb (11.046 righe finali contro
9.973 del solo match diretto, verificato via `SELECT COUNT(*)` a più stadi). Trattato come
caratteristica nota del dato, non filtrato/deduplicato in questo primo giro — stesso principio
già usato per il fan-out di Emesso/Diritti. Il JOIN interno verso `imdb.parquet` è sempre
`INNER` (una riga Gemma senza un codice IMDb valido/risolvibile non ha comunque modo di
agganciarsi ad Anagrafica); il JOIN verso Anagrafica segue la stessa regola automatica
LEFT/INNER degli altri domini.

**Campi**: tutti i 58 meno `A_COD_IMDB` (chiave di join, esclusa dall'output —
`A_CODICE_PRODOTTO` invece resta, è solo informativo ora che non è più la chiave). Nomi
esposti tutti minuscolo per coerenza col resto (`A_STATO` → `a_stato`, ecc. — corrispondenza
sempre `.upper()` in `_build_gemma_join`, le colonne reali nel parquet sono maiuscole).
`a_data`/`a_deadline` sono stringhe in formato **italiano** `GG/MM/AAAA` **grezze nel
parquet** (non un tipo `DATE` nativo come `decr`/`scad` di Diritti) — convertite a ISO tramite
`strptime()` nella subquery di join, poi ricastate a `VARCHAR` per lo stesso motivo di sempre
(altrimenti `jsonify` le serializza in formato RFC anziché ISO — bug trovato e corretto nello
stesso giro, prima del fix `a_data` usciva come `"Fri, 05 Aug 2016 00:00:00 GMT"`).

**Frontend**: blocchi `pb_gemma`/`pb_filtro_gemma`/`pb_gruppo_gemma`/`pb_join_gemma`, stesso
pattern degli altri quattro domini. Quinta famiglia colore, viola (Material Purple: primario
`#6A1B9A`, medio `#AB47BC`, chiaro `#E1BEE7`). Categoria "Gemma" propria nel toolbox.

Verificato su dati reali da Nave: SQL diretto a più stadi (fan-out, conteggi LEFT/INNER),
`test_client()` (join/filtri/validazione campo/date), `playwright` headless end-to-end
(blocchi, pseudo-codice, query reale, screenshot). **Non ancora testato visivamente** su
Ufficio.

## Consultazione standalone — deviazione deliberata dalla specifica ufficiale (06/08/2026)

`[CONFERMATO]` — la specifica ufficiale (`PowerBricks_Specifiche.md` §4) fissa Anagrafica come
**perno obbligatorio**: ogni query passa da lì, gli altri domini si uniscono ad Anagrafica, mai
tra loro direttamente. Mauro ha chiesto di rimuovere questo vincolo: ogni tabella satellite
(Emesso/Boxoffice/Diritti/Gemma) deve poter essere consultata **da sola**, senza dover mettere
comunque un blocco "Tabella Anagrafica" sulla lavagna — motivazione esplicita: "se uno deve
fare una verifica su una tabella così la può fare". Nato discutendo Gemma (il cui legame con
Anagrafica è già debole, 9,5% di copertura — lì il vincolo era più un ostacolo che un aiuto),
esteso esplicitamente a tutti i domini, non solo a Gemma. **Scope confermato con Mauro**: solo
consultazione a **tabella singola** (una sola tabella satellite alla volta, letta così com'è)
— combinare due tabelle satellite *tra loro* senza passare da Anagrafica resta fuori scope
(richiederebbe chiavi di join dirette tra coppie di satelliti, oggi non definite: se serve in
futuro, tema a sé).

**Meccanica**: se sulla lavagna non c'è "Tabella Anagrafica" ma c'è **esattamente una** tabella
satellite, quella diventa la fonte diretta della query (SELECT sui suoi campi grezzi, WHERE sui
suoi filtri, nessun JOIN) — non più "Serve un blocco 'Query Anagrafica'", ma "Serve almeno una
Tabella sulla lavagna". Se ce n'è più di una senza Anagrafica, errore esplicito che spiega la
scelta ("aggiungi Anagrafica per combinarle, o lasciane una sola"): niente comportamento
implicito/indovinato su quale tabella usare come base. Ogni dominio in modalità standalone
**salta la logica che esiste solo in funzione del legame con Anagrafica**: niente aggregazione
prima/ultima per Emesso (non c'è un'edizione di riferimento da aggregare), niente risoluzione
IMDb per Gemma (serviva solo a calcolare "prodotto" per il join, qui `gemma.parquet` si legge
così com'è) — Diritti mantiene comunque agganciata `diritti_enrich` (è "trasparente", parte
della stessa Tabella Diritti a prescindere dal contesto). Stessi cast dei campi data già in uso
per la modalità unita ad Anagrafica (necessari per la serializzazione JSON, non per il join).

Backend: nuova chiave `standalone: {domain, fields, filters}` nel body di `/api/query`/
`/api/open_grid`, alternativa (non aggiuntiva) alle chiavi esistenti — instradata prima di
`_parse_query_body`. `_standalone_base_sql(domain)` costruisce la FROM per dominio, riusando
gli stessi cast già scritti per la modalità unita ad Anagrafica ma senza la parte di
aggregazione/risoluzione. Frontend: `getQueryPayload` ora prova prima "Tabella Anagrafica" (se
presente, comportamento invariato), poi la lista `STANDALONE_DOMAINS`; il pannello
pseudo-lingua non mostra più l'etichetta `[join ...]` quando non c'è Anagrafica (sarebbe
fuorviante, non c'è nessun join in corso).

Verificato con `test_client()` (i quattro domini standalone, dominio/campo non validi
rifiutati, cast date corretti) e `playwright` headless end-to-end (tre casi: singola tabella
→ query reale, due tabelle senza Anagrafica → errore esplicito, lavagna vuota → nessun
payload). **Non ancora testato visivamente** su Ufficio.

## Pannello pseudo-lingua — primo passo verso "doppia modalità" (06/08/2026)

`[CONFERMATO]` — Mauro ha chiesto se fosse possibile ("a gratis") vedere il codice generato
dai blocchi. Discussa l'alternativa tra due strade: un generatore Blockly nativo (JS che
ricostruisce SQL leggendo i blocchi — richiederebbe una seconda implementazione della logica
filtri, rischio di disallineamento col backend) oppure un endpoint che restituisce l'SQL vero
già costruito dal backend (nessuna duplicazione, ma sola lettura). Mauro ha poi chiarito
l'obiettivo a tendere: **utenti avanzati devono poter modificare il testo direttamente**, non
solo leggerlo — questo esclude l'SQL vero come superficie editabile (parsare SQL scritto a
mano per ricostruire i blocchi è complesso/rischioso) e riporta alla **pseudo-lingua** già in
agenda (vedi "Doppia modalità blocchi + pseudo-linguaggio" sopra, 04/08) — sintassi propria,
pensata apposta per un parsing deterministico nei due sensi.

**Implementato (solo visualizzazione, editing rimandato)**: `generatePseudoCode(workspace)`
in `app.js` — riusa `blockToNode`/`collectChain`/`collectFilters` (gli stessi alberi mandati
al backend in `getQueryPayload`), quindi nessuna seconda implementazione della logica filtri:
l'anteprima non può andare fuori sincrono da quello che "Esegui query" manda davvero.

Sintassi: nome dominio in testa (`Anagrafica`/`Emesso`/`Boxoffice`), filtri indentati sotto,
AND implicito tra blocchi in sequenza sullo stesso slot (stessa semantica di `_build_where`
lato backend), parentesi per i gruppi annidati con l'operatore del gruppo prima di ogni
figlio successivo, annotazione `[join ...]` accanto al nome per Emesso/Boxoffice quando
presente. Esempio reale (verificato):

```
Anagrafica
  prodotto = 123
  AND (
    tipologia = "FILM"
    OR anno_produzione ≥ 2000
  )

Emesso  [join LEFT forzato]
  rete = "I1"
```

**UI**: pannello a comparsa in fondo alla finestra (bottone "Mostra codice"/"Nascondi codice"
in toolbar), stile "console" scuro monospace per distinguerlo dal canvas. Aggiornato ad ogni
modifica del workspace (`workspace.addChangeListener`) con debounce 150ms.

Verificato da Nave con `playwright` + `google-chrome` headless (non installato prima, ora
disponibile: browser Chromium via `npx playwright install chromium`, non serve per l'uso
normale dell'app, solo per questo tipo di verifica visiva automatizzata) — sia il caso vuoto
sia un caso con filtri/gruppo annidato/join popolati via API Blockly diretta (`newBlock`,
`setFieldValue`, connessioni statement) invece che trascinamento reale.

**Non implementato**: editing del testo con sync verso i blocchi (richiederebbe un parser
per la pseudo-lingua, direzione testo→blocchi) — resta il prossimo passo naturale quando si
vorrà affrontarlo.

## Grafica query builder — colore per dominio, stile MediaTrack (05/08/2026)

`frontend/index.html`/`app.js`: struttura/gradienti/font presi da
`PYTHON/MyICR_Suite/app/modules/mediatrack/frontend/style.css` (sfondo `#f5f5f5`, font Segoe
UI, toolbar con gradiente `#f8f8f8→#e8e8e8`) — questa parte non cambia.

**Anagrafica → rosso pastello (deciso definitivamente, 05/08/2026)**: dopo un giro intermedio
sul verde acqua (motivato dall'idea "un colore per dominio, rosso riservato al futuro"), Mauro
ha richiesto di tornare al rosso per Anagrafica — il colore per dominio resta un principio
valido per quando arriveranno Emesso/Diritti/Boxoffice, ma Anagrafica stessa è rossa, non il
verde acqua del giro intermedio. Famiglia: primario `#C62828`, medio `#E57373`, chiaro
`#EF9A9A` (stessa già in uso per i pulsanti "danger" di `MonitorOsservatorioPy`). Applicato a
pulsante primario "Esegui query" e "Applica" nel modale (gradiente `#E57373→#C62828`), testo
di stato e titoli modale (`#C62828`), blocchi Blockly (`pb_query` `#C62828`, `pb_gruppo`
`#E57373`, `pb_filtro` `#EF9A9A`), marcatore di inserimento nel workspace (`#C62828`).

**Splash screen**, stesso famiglia rossa del resto (coerenza, non più "colore a parte" come
nel giro intermedio col verde acqua). Timer di dissolvenza: 4600ms (allungato da 1600ms su
richiesta esplicita — "il ritardo l'abbiamo messo apposta per guardarlo"). Stesso
pattern/meccanismo di `PYTHON/MonitorOsservatorioPy` (overlay `position: fixed` a schermo
intero, dissolvenza CSS + rimozione dal DOM). Le lettere di "Bricks" restano a colori vivaci
alternati (rosso, giallo, blu, verde, arancio — stile mattoncini LEGO): ogni lettera in uno
`<span>` proprio, colorato via `:nth-child` in CSS — solo decorazione dello splash, non tocca
il resto della UI.

**Rivista il 06/08/2026 dopo due giri di feedback** (Mauro l'ha guardata sul serio, complice
il timer allungato apposta): il design originale sfumava verso il bianco puro
(`#E57373→#ffffff`, "degradazione soft" stile MediaTrack) — giudicato "il rosa di sfondo non
mi fa impazzire, andrebbe fatto più carico, sfumarlo al bianco è probabilmente troppo". Sfondo
ora un gradiente tra due rossi pieni, mai verso il bianco: primo giro `#C62828→#E57373`
(giudicato troppo intenso), alleggerito a `#D32F2F→#EF9A9A` (validato: "carino ed elegante").
**Testo bianco pieno** (non più opacità 0.92) — un tentativo di testo rosso scuro era già
stato scartato in passato, poco leggibile contro lo sfondo rosso, non riproposto in questo
giro. Titolo e sottotitolo ingranditi (46px→64px, 11px→15px). Sottotitolo generico "Query
Builder" (tolto "— Anagrafica": lo splash è del prodotto, non del dominio aperto quella
sessione). Aggiunto un **reticolo puntinato di sfondo** che riprende lo stesso pattern del
workspace Blockly (`radial-gradient` a puntini, 20px di spaziatura, stessa misura del
`grid.spacing` di Blockly) — filo visivo tra la schermata d'attesa e il canvas che si apre
subito dopo — e una piccola **animazione d'ingresso** (fade + risalita di 10px, titolo poi
sottotitolo con 150ms di ritardo), per usare il tempo di attesa invece di restare un'immagine
ferma.

**Sfondi toolbox/flyout/workspace Blockly**: impostati via un `Blockly.Theme` dedicato
(`mediatrackTheme`, base `Blockly.Themes.Classic` con `componentStyles` sovrascritti): flyout
e toolbox `#f5f5f5` (stesso grigio di MediaTrack, invariato), workspace bianco. Passato a
`Blockly.inject()` come
opzione `theme`.

## Dati

Legge `prodotti.parquet` da `../../PYTHON/MyICR_Suite/local_db/parquet/prodotti.parquet`
(path relativo, stessa struttura su Nave e Ufficio) — **sola lettura**, 226431 righe, 25
colonne (schema completo via `DESCRIBE` in backend/server.py). Nessuna scrittura su questo
file: è il mirror sincronizzato via Dropbox, non toccarlo.

Tutte le 25 colonne sono esposte come campi filtrabili (ampliato da un sottoinsieme di 9,
05/08/2026 — servivano tutte per la fase di test su limiti/potenzialità).

**Output selezionabile** (doppio click sul blocco `pb_query`, vedi Stack sopra) — default:
tutte le 25 colonne finché non si apre il modale e si sceglie diversamente.

## Entry point

```
python run.py
```

Avvia Flask in thread demone + finestra pywebview puntata a `http://127.0.0.1:5050`
(porta diversa da MediaTrack/5000 per poter girare in parallelo).

## Stato (aggiornato 06/08/2026)

Cinque domini implementati: Anagrafica, Emesso, Boxoffice, Diritti, Gemma — tutti con WHERE
(filtri + gruppi AND/OR annidati) e SELECT (modale a doppio click) completi, blocchi "Tabella"
container indipendenti, join di default automatica (INNER-se-filtri-altrimenti-LEFT) con
blocco ponte dedicato per forzarla esplicitamente. Diritti espone solo campi grezzi del
contratto (niente logica derivata: titolarità/passaggi residui/first-run-re-run/inibizioni
restano un layer a sé, vedi sezione dedicata sopra). Gemma si unisce tramite codice IMDb
(non un codice prodotto diretto — richiesto esplicitamente da Mauro) con fan-out noto e
accettato (`imdb.riferimento_imdb` non univoco). Diritti e Gemma sono gli unici due non
ancora validati da Mauro di persona (verificati da Nave: SQL diretto, `test_client()`,
`playwright` headless). Toolbox a categorie per dominio. Pannello pseudo-lingua (anteprima
testuale, sola lettura) aggiunto sopra i blocchi, copre correttamente tutti i domini (bug di
copertura Boxoffice trovato e corretto durante il giro Diritti). Tipo "date" nei filtri
(bug reale trovato da Mauro su Ufficio: `decr`/`data_emissione`/`data_debutto` non
supportavano confronti come `gte`, corretto per tutti e tre insieme). Griglia risultati
**migrata a componente web `datagrid` riusabile** (07/08/2026, sezione dedicata sopra),
aperta in una seconda finestra pywebview invece del vecchio processo PyQt6 separato.
Reticolo puntinato con snap nel workspace Blockly. **Anagrafica non è
più obbligatoria** (deviazione deliberata dalla specifica ufficiale, vedi sezione dedicata):
ogni dominio satellite si può consultare da solo, senza perno comune — solo a tabella singola,
non ancora combinazioni di satelliti tra loro.

**Non ancora fatto**: la logica di business di Diritti (percentuali titolarità, passaggi
residui, first-run/re-run, inibizioni — "il cuore del valore" secondo la specifica ufficiale,
il pezzo di sforzo più grosso rimasto); editing testo→blocchi nel pannello pseudo-lingua
(richiede un parser, direzione inversa rispetto a oggi che è solo blocchi→testo); verifica
visiva su display reale di Diritti e Gemma, del blocco ponte `pb_join`/griglia PyQt6 assieme a
tutti i domini (fatta finora solo via backend/contratto/playwright da Nave, headless).