--- name: lavoro-python-ecosistema description: "Panoramica dei progetti sotto PYTHON/ (ufficio Windows Mediaset) — hub, un file per applicativo" metadata: type: project --- Parte di [[_i_lavoro|lavoro]] (contesto professionale di Mauro) — complementare a [[lavoro-progetti-strumenti]], che racconta MyICR Suite/PowerBricks/Linker dal lato posizionamento strategico; questa cartella è l'inventario tecnico dell'intero codice ufficio, non solo i progetti citati lì. `Dropbox/adrian/PYTHON/` è il codice dei progetti ufficio Mediaset di Mauro — territorio Windows, sola lettura da Nave (v. [[feedback_python_windows_territory]]), **fisicamente fuori dall'archivio**. Un'AI che consulti solo `archivio/` (es. un mirror esterno) non lo vede affatto: questa cartella esiste per colmare quel buco, dando il quadro "chi fa cosa" senza bisogno di entrare in `PYTHON/`. **Gotcha (04/08/2026): falsi "modificati" per line-ending, visibili solo da Nave.** `git status` dentro `PYTHON/` da Nave (Linux) può segnare file come modificati (tipico su CSV/config/VBA) quando in realtà il contenuto è identico e cambia solo il terminatore di riga (CRLF↔LF) — verificabile con `git diff -b` (ignora whitespace), che in questi casi non mostra nulla. Causa: Git per Windows normalizza CRLF↔LF in automatico (autocrlf), da Ufficio il repo risulta pulito; Nave non ha quella normalizzazione e vede il working tree sincronizzato via Dropbox come divergente dal blob committato. Non è un problema reale, non richiede né commit né altra azione — non sparirà mai finché non si configura `.gitattributes` (oggi assente), ma è innocuo e va ignorato quando lo si incontra in un controllo da Nave. **Non è una copia dei CLAUDE.md di progetto** — quelli restano la fonte di verità tecnica (stack, comandi, gotcha implementativi) e vivono con il codice. Ogni file qui ha solo: cosa fa, che stato ha, come si collega agli altri. Per l'indice tecnico completo con path: `PYTHON/CLAUDE.md` (coordinator, letto solo da chi ha accesso a `PYTHON/`). **Per la business logic e i flussi dati** (dove nascono i dati OnAir, come li trasforma la pipeline SCHEDULATORE, anomalie): non qui, vedi [[flussi-expert]] (logistica/pipeline) e [[data-expert]] (semantica di business) — coprono in profondità PIPELINE_PYTHON/DataHub_v2/ParquetToAccess e l'ecosistema MyICR_Suite/PowerBricks, molto più in dettaglio di quanto serva ripetere qui. **Convenzione git (completata 04/08/2026)**: ogni progetto di primo livello sotto `PYTHON/` ha ora un repository git proprio (repo annidato, agganciato al padre solo come puntatore a commit — mode `160000`) — scelta esplicita di Mauro per avere nel pannello Source Control di VSCode uno storico pulito per progetto, invece di un unico log misto. `PIPELINE_PYTHON` era l'ultima eccezione (file tracciati direttamente nel repo padre), sistemata oggi: repo proprio creato da zero (storia precedente, inclusi i fix del 04/08, resta recuperabile nella storia del repo padre `PYTHON/` prima del commit `b647a74`). Nessuno di questi è un submodule "ufficiale" (manca `.gitmodules` nel padre) — funzionano come repo annidati informali, sufficiente per l'uso attuale ma non supportano i comandi `git submodule` standard. **Repo padre `PYTHON/` rimosso (04/08/2026)** — con tutti i progetti ormai autonomi, il `.git` del padre non serviva più a nulla (la sua unica funzione residua, tracciare i puntatori submodule, era superflua). Rinominato in `.git-archiviato-20260804` (non cancellato — resta recuperabile, rinominare indietro se mai servisse). **Non cancellare questa cartella nel breve periodo**: contiene l'unica copia recuperabile della storia commit precedente di `PIPELINE_PYTHON` (incluso il fix `db_Osservatorio`/`integrazione_update_day` del 04/08, non portato nel nuovo repo standalone per scelta esplicita — "partenza pulita" era considerato rischio basso solo perché questa copia restava disponibile come rete di sicurezza). Decisione di Mauro (04/08/2026): aspettare qualche settimana di uso reale del nuovo assetto prima di valutare l'eliminazione definitiva. **Root ripulita del tutto (04/08/2026)**: oltre ai 5 file morti trovati per primi (`Bill.txt`, `KERNEL.md`, `agenda.md`, `_analyze_parquet.py`, `_check_emesso_dupes.py` — vault-mcp/Bill/path pre-migrazione), un secondo giro ha trovato altri 3 file di configurazione altrettanto morti: `.mcp.json` (puntava a `vault.privcloud.dev`, lo stesso vault-mcp smantellato), `.env` (solo credenziali Supabase, dismesso 06/07), `.gitignore` (inerte, nessun `.git` più lo legge). Tutti eliminati. **Oggi la root di `PYTHON/` contiene solo `CLAUDE.md`** — nessun altro file sciolto, nessun rischio residuo di credenziali morte in giro. **⚠️ Gotcha di sicurezza — `PYTHON/` non ha più un confine di repo suo.** Da quando il `.git` padre è stato rimosso, `git rev-parse --show-toplevel` lanciato da dentro `PYTHON/` (o qualunque sua sottocartella priva di `.git` proprio) risale fino a trovare `Dropbox/adrian/.git` — il repo principale, lo stesso su cui lavora Adrian da Nave. `PYTHON/` resta protetto da un `.gitignore` nel repo principale (`git add`/`git add -A` non lo raccolgono), ma un comando come `git commit -a` lanciato per errore da dentro `PYTHON/`, pensando di essere in un repo locale isolato, committerebbe invece nel repo principale — prendendo dentro anche eventuali modifiche pendenti non ancora committate su `archivio/`. **Prima di qualunque comando git che non sia un semplice `git status`/`git log` mirato a un sottoprogetto con `.git` proprio, lanciare `git rev-parse --show-toplevel` per verificare in quale repo ci si trova davvero.** ## Applicativi Un file per progetto — nome identico alla cartella reale sotto `PYTHON/` (fisico e logico allineati): - [[Frank]] — daemon Windows, orchestra i job ETL (ex Scheduler) - [[schedulatore-job-status|gate-ufficio]] — esecutore muto che ha sostituito Frank, tutti i 6 job migrati (04/09). Fonte unica di stato (job + backup), non narrativa — la storia del progetto (tunnel dismantellato, migrazione) vive solo nei log commit git. - [[MyICR_Suite]] — suite applicativa ICR, il cuore dell'ecosistema - [[PIPELINE_PYTHON]] — pipeline CSV→Parquet→Access/SQLite, a monte di tutto - [[ImdbUpdate]] — job settimanale dataset IMDb - [[GemmaReport]] — report automatico settimanale prodotti GEMMA - [[GemmaClient]] — client desktop per GEMMA GSV - [[DbComparer]] — validazione DB, uso on-demand - [[MonitorOsservatorioPy]] — ascolti TV Spagna/Germania - [[PowerBricks]] — query builder visuale per colleghi, seme dormiente (zero codice) — cartella eliminata da `PYTHON/` il 04/08/2026, materiale storico solo in archivio (`PowerBricks-raw/`) - [[PowerBricks-appunti]] — appunti rapidi di stato corrente/prossimi passi/idee non ancora scoped, consultazione veloce: il dettaglio/motivazioni restano in `PowerBricks.md` - `omdb_enrich` — **trovato 04/08/2026, non ancora documentato**: nessun CLAUDE.md, non in `PYTHON/CLAUDE.md`. Dai nomi file (`omdb_batch_enrich.py`, `omdb_poster_repair.py`) sembra arricchimento metadati/poster da OMDB — da verificare con Mauro e scrivere una scheda propria quando c'è tempo, per ora solo segnalato per non perderlo. ## Quando aggiornare questa cartella Su cambio di status (active→completed, nuovo progetto, smantellamento) o su una nuova relazione strutturale tra progetti — non sui dettagli implementativi, quelli restano nei CLAUDE.md locali. Fonte primaria per verificare lo stato corrente resta `PYTHON/CLAUDE.md` (chi ha accesso a `PYTHON/`, quindi non un'AI esterna solo su archivio). Nuovo progetto → nuovo file qui, stesso nome della cartella reale.