--- name: project-expert-myicr description: "Idea in discussione (03/09/2026, non implementata) — istituire un quarto esperto persistente dedicato al codice applicativo di MyICR Suite, nato dall'incidente OTT del 02/09/2026. Canvas di raccolta idee prima di procedere, non ancora una decisione." metadata: type: progetto --- # Expert MyICR Se istituire un quarto esperto persistente dedicato al codice applicativo di MyICR Suite — nato dall'incidente OTT del 02/09/2026, che ha mostrato quanto questa conoscenza oggi sia dispersa e scoperta solo per caso durante le indagini. Canvas di raccolta idee, 03/09/2026 — non implementato, thread aperto. **(10/09/2026)** Prima di decidere questo esperto specifico, si è aperta una discussione più generale sullo standard che ogni esperto dovrebbe seguire (memoria, composizione tra esperti) — vedi [[project_standard_esperti]], che resta a monte di questo canvas. ## Cosa ha fatto emergere l'idea - Passo 20 (incidente OTT, 02/09/2026): scoperto il meccanismo reale di `_carica_file()` in `ott_sheet.py` — push al server asincrono, UI che conferma successo prima della conferma reale, fallimento silenzioso solo in `logger.warning`. Gap: nessun indicatore in UI distingue "salvato in locale" da "arrivato sul server" — l'utente non ha modo di saperlo finché non sorge un dubbio e si va a verificare a mano. - La scoperta è finita dentro `flussi-expert.md` solo perché emersa durante un'indagine sui flussi dati, ma concettualmente è conoscenza applicativa (comportamento del codice), non provenienza/trasformazione dati — scope creep già in atto in quel documento. - Thread già aperto dal 07/08/2026 (generalizzazione PowerBricks → smantellamento PyQt6): "subagente MyICR — da rivalutare come esperto invece di subagente", mai chiuso, vedi `archivio/Mauro/lavoro/lavoro-python-ecosistema/PowerBricks.md`. - (04/09/2026) `database_logic.py:2815` (`mark_omdb_not_found`) faceva `INSERT` solo se il record non esisteva, nessun `UPDATE` su stub già marcati "non trovato" — bug reale trovato durante un test del job `omdb_batch_enrich`, corretto lo stesso giorno (commit `b65261d`). Dettaglio: `memory/MEMORY.md`, `archivio/Mauro/lavoro/lavoro-python-ecosistema/schedulatore-job-status.md`. - (04/09/2026, stesso giorno, terzo caso) `database_logic.py` apre/chiude una connessione SQLite nuova per ogni singola chiamata helper (`_conn()`) invece di condividerne una per l'intero batch — su `mediatrack.db` in condivisione di rete (`I:\`), con probabile contesa da altri processi (utenti MyICR_Suite, sync periodico ogni 5 min), questo pattern è fragile: il job `omdb_batch_enrich` è crashato con `sqlite3.OperationalError: database is locked` al record 729/2000 (primo run reale dopo lo sblocco del bug sopra), nessun retry/backoff da nessuna parte sul lock. Nessuna perdita dati (commit per-record) — il job riparte lunedì senza intervento. Deciso con Mauro: fix in coda, non ora — proposta pronta se si riprende: retry/backoff su `OperationalError`, 3 tentativi con attesa crescente. ## Il filo del ragionamento Mauro segnala che il problema OTT del giorno prima, anche se rientrato da solo, deve far riflettere — occasione per migliorarsi, non solo un incidente chiuso. Adrian propone due livelli di intervento sul caso specifico: fix mirato su `ott_sheet.py` (UI attende la conferma del push), oppure ricognizione più ampia per capire se lo stesso pattern (scrittura locale sincrona + push server asincrono silenzioso) esiste altrove in MyICR_Suite. Mauro rilancia — invece di procedere sul caso specifico, valutare se è arrivato il momento di istituire un expert dedicato a MyICR. Adrian valuta positivamente: la conoscenza di "come si comporta l'applicativo" oggi non ha una casa pulita, distinta da `expert-flussi` (provenienza/trasformazione dei dati) ed `expert-data` (semantica di business dei dati). Prima di procedere, Mauro vuole raccogliere le idee su un canvas — cosa farebbe esattamente questo expert — invece di partire subito con l'implementazione. Da tenere presente: è confermato che `SendMessage` funziona anche tra Nave e PC ufficio (usato dal vivo durante l'incidente OTT del 02/09). Quindi resta da definire dove sia meglio far vivere questo expert, non è più scontato che debba stare su Nave solo perché è lì che vivono gli altri tre. ## Dove vive l'expert — Nave o Ufficio **Aperto.** Finché ha senso solo leggere codice, la scelta non è vincolante: `PYTHON/` sincronizza via Dropbox+git, sempre leggibile da entrambe le macchine. Cambia se serve *osservare l'app in esecuzione*. - Su Nave: legge `PYTHON/MyICR_Suite/` come tutti gli altri esperti, ma è cieco sulla GUI PyQt6 reale (headless, nessun display) — vede solo il codice sorgente, mai il comportamento a schermo. - Su Nave: per `sandbox/powerbricks/` (prototipo web Flask+JS) può verificare comportamento reale via Playwright headless, stesso meccanismo già validato per altri prototipi — qui il limite sopra non vale. - Su Ufficio: vedrebbe la GUI PyQt6 vera, ma richiederebbe una sessione Ufficio sempre viva (oggi non hanno keep-alive come gli esperti Nave — vedi `memory/MEMORY.md`, Pending "Keep-alive per sessioni Remote Control su Ufficio"). - Con `SendMessage` cross-macchina confermato, un Adrian su Nave può comunque raggiungere un expert che vive su Ufficio: la domanda non è più "dove per essere raggiungibile" ma "dove ha visibilità migliore sul suo dominio". ## La proposta **Aperto.** Un quarto esperto persistente, stessa classe di `expert-data`/`expert-domotica`/ `expert-flussi`: raggiunto sincrono via `SendMessage` per una domanda puntuale di dominio, mai un evento continuo da sorvegliare. - Dominio: architettura e comportamento del codice di `PYTHON/MyICR_Suite/` (Linker, moduli, launcher) + `sandbox/powerbricks/` (la migrazione web in corso). - Cosa copre: meccanismi UI, fragilità di design, business logic embedded nel codice (es. il workaround DVB-T del Passo 18, il push asincrono OTT del Passo 20) — non semantica dei dati, non provenienza dei dati. - Postura: sola lettura su `PYTHON/`, mai scrittura — stessa regola costituzionale già valida per gli altri esperti. - Tratto obbligatorio di ruolo: segnala di propria iniziativa ogni problema/miglioramento possibile trovato, senza mai decidere da solo se intervenire. ## Confini con gli altri esperti - `expert-data` resta lo specialista di cosa *significa* un valore/campo nel dato — nessuna sovrapposizione. - `expert-flussi` resta lo specialista di *da dove viene* un dato e che pipeline lo trasforma prima di arrivare nei parquet/mirror — nessuna sovrapposizione. - `expert-myicr` (nome proposto): specialista di *come si comporta l'applicativo* che quei dati li consuma/mostra/scrive — perimetro nuovo, ancora da confermare del tutto. ## Domande aperte - Dove vive: Nave (coerente con gli altri tre esperti, ma cieco sulla GUI PyQt6 reale) o Ufficio (visibilità nativa sulla GUI, ma richiede una sessione Ufficio sempre viva) — vedi sezione dedicata sopra. - Nome definitivo: `expert-myicr` (proposto, da confermare). - Il Passo 20 (meccanismo OTT), oggi dentro `flussi-expert.md`: spostarlo nella nuova base di conoscenza o lasciarlo lì per storia e partire pulito da qui in avanti? - Perimetro applicativi: solo `MyICR_Suite` + `sandbox/powerbricks`, o includere anche gli altri Tier1 collegati (`DbComparer`, `GemmaReport`, `ImdbUpdate`)? - Base di conoscenza iniziale: parte vuota e si costruisce domanda su domanda, o si fa prima un passaggio di ricognizione dedicato (come è stato fatto all'inizio per `data-expert`/ `flussi-expert`)? ## Stato Non implementato. Nessuna implementazione senza approvazione esplicita di Mauro.