Wiki Progetto di Ricerca Metodo Paret

Cantieri aperti: differenze tra le versioni

[versione verificata][versione verificata]
← Differenza precedenteDifferenza successiva →
VisualeWikitesto
WikiBot (discussione | contributi)
Ricercatori, Bot, Burocrati, Amministratori
3 931 modifiche
handoff automatico
WikiBot (discussione | contributi)
Ricercatori, Bot, Burocrati, Amministratori
3 931 modifiche
handoff automatico
Riga 7: Riga 7:


== Cantieri attivi ==
== Cantieri attivi ==
=== migrazione-aigw ===
''Aggiornato 2026-08-12 08:08 UTC'' — dominio: infrastruttura AI / gateway
; Obiettivo : Far passare TUTTI i client AI dal gateway aigw, per avere log e cost guard inaggirabili, e poi ruotare le chiavi provider
; Fatto (con prova) :
* VERIFICATO che il gateway aigw esiste ed e reale: systemd active su translator, /opt/aigw/aigw.py, calls.jsonl con 7 chiamate vere loggate fra cui oracolo-agent su glm-5.2 e client cc su deepseek-chat, con token in/out e costo
* LANCIATO in asincrono il censimento che mancava: job censimento_aigw, scripts/censimento_aigw.py. Cerca su VM, translator e media quali script usano ancora sk-or-v1, api.deepseek.com, openrouter.ai, dashscope, moonshot direttamente invece del gateway. Sola lettura, nessuna modifica. Esito in gs state/migrazione_aigw.json
* CHIUSO UN BUCO in chiusura.py: la regex dei rinvii copriva nella prossima sessione al singolare ma non nelle prossime sessioni al plurale, ne progressivamente, man mano, a tappe. Aggiunto anche il gruppo CODA: la coda della, li migro, restano da fare. Provato sul testo reale: ora pesca tutti e tre i punti piu la mancanza del contratto
; Provato ed escluso :
* Migrare gli script automaticamente senza prima censirli: circa 14 sul VM era una stima, non una lista. Il censimento produce la lista vera con quali girano da cron
* Ruotare le chiavi provider prima che lultimo client sia migrato: spacca i non migrati
; Prossimo passo :
* Leggere lesito di censimento_aigw e migrare per priorita, partendo dagli script in cron
* Hermes: config non trovata al primo giro, va cercata
* Solo a migrazione completa ruotare le chiavi provider: da quel momento la policy e fisicamente inaggirabile
=== finanze-classificazione ===
''Aggiornato 2026-08-11 15:08 UTC'' — dominio: contabilita / finance
; Obiettivo : Chiudere il buco DA_CLASSIFICARE e impedire che il lavoro venga azzerato ogni notte
; Fatto (con prova) :
* CREATO routing file FINANZE.md, su Drive id 176Tw19NgXPszcTEtPJEgbrjT00iD2a7i, verificato 4.696 byte
* CENSITO cosa esiste gia in isicnv_finance: 105 tabelle e 19 viste, fra cui v_costi_per_categoria, v_spese_azienda, v_spese_aziendali_da_conto_personale, v_finance_quinquennale, v_riconciliazione_allievi
* TROVATA la causa vera del blocco: classification_rules ha 678 regole agganciate al campo counterparty, ma controparte_nome e NULL su TUTTE le 8.389 righe DA_CLASSIFICARE. Le regole non possono agganciare nulla
* MISURATO: derivando la controparte con TRIM(IF(direction=OUT, dst_name, src_name)) si classificano subito 3.413 movimenti pari a 666.086 euro, il 38 per cento, senza scrivere una regola nuova
* Stato attuale: DA_CLASSIFICARE 8.389 mov / 1.743.096 eur, DA_CHIARIRE 98 mov / 200.025 eur
* ESEGUITO. Backup transactions_multianno_bak_20260809 (14.492 righe)
* controparte_nome popolato su tutte le 8.389 righe da src_name/dst_name secondo direction
* Applicate le 678 regole di classification_rules: 3.413 movimenti classificati, DA_CLASSIFICARE sceso da 8.389 a 4.976 movimenti e da 1.743.096 a 1.077.010 euro. Marcati con classifier_blob auto:classification_rules:20260810
* Categorie assegnate: INCOME_CORSI 1.116 mov 472.134 eur, PERSONAL 431, BIZ_FOR_UNIVERSITE 197, PERSONAL_GENUINE 404, MARKETING 96, CASH 57, ANNA_FAMILY 76, REVIEW 353, TRASPORTI 166, STAFF 33, TRAVEL 40, TECH 353, LEGAL 12, INTERCOMPANY 13
* INTEGRITA VERIFICATA: 14.492 righe prima e dopo, somma importi 4.351.207 identica
* REGOLE DI MARCO INSERITE in classification_rules e applicate: LIGHTNING SOURCE -> INCOME_LIBRI (royalties, e IN non OUT: sono ricavi non costi di stampa), Di Feo Gioacchino -> INCOME_CORSI VIP COURS, Alena Telezin -> INCOME_CORSI corso Svizzera, IPCA -> INTERCOMPANY collaborazione associazione italiana, To GBP e To EUR -> FX conversioni interne Wise
* Assegnati: FX 50 mov 51.572 eur, INCOME_CORSI 7 mov 41.750, INCOME_LIBRI 3 mov 24.965, INTERCOMPANY 9 mov 20.000
* RESIDUO ora 4.907 mov / 938.723 eur (partenza 8.389 / 1.743.096)
* INDAGINE sui 113 (da identificare): tutti IN su Universite apr-lug 2026, causali loan 15.050, vuota 8.374, Wages 7.094, bonus, rimborsi progetto, May Rent, fatture, Saldo corso Roma, quote iscrizione
* Gmail isicnv interrogabile via token-any-isicnv: le notifiche Wise Denaro ricevuto da X contengono il nome mancante. Estratte 12 mail con nome (TODARO STEFANIA, MORRONI CRISTIANA, Giuseppe Giudice, BERTON LINE SRL, Daniele Pacioni, D ALONZO ELISA, PRIVITERA ANTONINO, DONATI NAZZARENO...) in /home/claudeuser/wise_mail_match.json
* FALSO SUCCESSO SCOPERTO: tutto il lavoro di classificazione del 10 agosto (3.413 movimenti miei piu circa 1.700 di unaltra chat) era stato AZZERATO. DA_CLASSIFICARE era tornato a 8.389 mov / 1.743.096 euro, il numero esatto di partenza, mentre i marcatori in classifier_blob restavano a dire che il lavoro era stato fatto
* CAUSA TROVATA: finance_daily_sync.py alle 06:45 ha un passo chiamato classificazione che riscrive la colonna category da zero e riporta a DA_CLASSIFICARE tutto cio che le sue regole interne non riconoscono. Confermato da INFORMATION_SCHEMA.JOBS_BY_USER: catena di UPDATE alle 06:49-06:51 su category e perimetro, e ultima modifica tabella alle 06:50:29
* RIMEDIO: creato scripts/riapplica_regole.py, in cron alle 07:10 (dopo il sync). Ripopola controparte_nome e riapplica classification_rules
* BUG TROVATO NEL RIMEDIO: dopo le 6 regole aggiunte ieri alcune controparti erano doppie e BigQuery rifiutava con UPDATE must match at most one source row. Aggiunta deduplica con ROW_NUMBER sulla piu recente
* RIPRISTINO ESEGUITO: da 8.389 a 4.646 movimenti, da 1.743.096 a 702.043 euro
* USATA la libreria google.cloud.bigquery al posto della CLI bq: la CLI perdeva le regex nei livelli di escaping e l UPDATE tornava False senza errore visibile
* la libreria restituisce num_dml_affected_rows
; Provato ed escluso :
* Riclassificare a mano controparte per controparte come proponeva laltra chat: e lavoro gia fatto, 678 regole esistono. Il problema non erano le regole ma il campo vuoto
* Fidarsi dei nomi di colonna italiani: il ledger usa date amount_src category description NON data importo categoria
* Scrivere il marcatore nel campo note: e FLOAT64 non STRING, lUPDATE fallisce. Usare classifier_blob che e STRING
* Riclassificare a mano controparte per controparte prima di aver popolato controparte_nome
* Recuperare i nomi dai dati grezzi: recent_2026_raw ha sender valorizzato solo su 19 righe su 334 nel periodo, merchant zero. Il nome NON e nei grezzi
* Il campo note e FLOAT64: usare classifier_blob per i marcatori
* Solo 12 notifiche Wise nel periodo contro 113 movimenti: la posta copre una minoranza dei casi
* Modificare la logica interna del passo classificazione del sync: rischioso e non necessario. Meglio un passo additivo dopo, che riapplica la fonte di verita classification_rules
* Fidarsi di un ESITO FATTO senza ricontrollare il giorno dopo: era vero quando scritto e falso dodici ore dopo
* Stringhe SQL con apostrofo (Spese per l ufficio): usare ScalarQueryParameter
; Prossimo passo :
* Aggiungere alla sentinella notturna il controllo che DA_CLASSIFICARE non risalga
=== harness-standard ===
=== harness-standard ===
''Aggiornato 2026-08-11 08:37 UTC'' — dominio: architettura / knowledge base
''Aggiornato 2026-08-12 08:52 UTC'' — dominio: architettura / knowledge base


; Obiettivo : Sostituire il MASTER READ ORDER monolitico con un harness gerarchico e togliere Marco dal ruolo di loop di esecuzione
; Obiettivo : Sostituire il MASTER READ ORDER monolitico con un harness gerarchico e togliere Marco dal ruolo di loop di esecuzione
Riga 149: Riga 92:
* MASTER v7.9 pubblicata e verificata, txt id 1r6u6-HQa_e0xaNSAUwhepEVs3glNXasa
* MASTER v7.9 pubblicata e verificata, txt id 1r6u6-HQa_e0xaNSAUwhepEVs3glNXasa
* ARCHITETTURA ORA COMPLETA: tre filtri a tre porte diverse. continua.py alle domande, resta.py alle liste, chiusura.py alluscita. Tutti e tre possono solo TOGLIERE interruzioni, mai aggiungerne
* ARCHITETTURA ORA COMPLETA: tre filtri a tre porte diverse. continua.py alle domande, resta.py alle liste, chiusura.py alluscita. Tutti e tre possono solo TOGLIERE interruzioni, mai aggiungerne
* CENSIMENTO GATEWAY concluso: 289 script usano ancora chiavi provider dirette, non i 14 stimati. 5 girano da cron sulla VM. Lista in gs state/migrazione_aigw.json
* COSTRUITO gate_master.py: cancello di pubblicazione che misura un Master candidato contro il precedente prima di pubblicarlo, principio Harness-R1
* SCOPERTA CRITICA sulla nostra misura: lo STESSO documento v7.6 valutato tre volte da 5, 2, 4. Il candidato v7.9 da 2, 4, 5. Mediana identica 4. La varianza del giudice e di 3 punti su 6, quindi leval NON PUO oggi distinguere un miglioramento da un peggioramento di 1 punto
* Questo invalida retroattivamente due conclusioni: la v7.7 non era necessariamente peggiorata (5 a 4 era rumore) e il confronto Qwen 3/6 contro DeepSeek 4/6 non e significativo
* La sentinella notturna ha una regola su eval_pass in calo: con questa varianza produrra falsi allarmi
; Provato ed escluso :
; Provato ed escluso :
* Adottare ahar / agentharnesses-cli: presuppone Claude Code su repo locale, Marco lavora da smartphone via route CC
* Adottare ahar / agentharnesses-cli: presuppone Claude Code su repo locale, Marco lavora da smartphone via route CC
Riga 175: Riga 123:
* Fidarsi del numero dei 16 giorni: non trovato in nessuna fonte
* Fidarsi del numero dei 16 giorni: non trovato in nessuna fonte
* Aggiungere regole al Master sperando che vengano lette: il buco esisteva perche i filtri guardavano le domande e le liste, non il messaggio. Il controllo va messo dove si passa davvero, cioe alluscita
* Aggiungere regole al Master sperando che vengano lette: il buco esisteva perche i filtri guardavano le domande e le liste, non il messaggio. Il controllo va messo dove si passa davvero, cioe alluscita
* Pubblicare una versione del Master senza misurarla: e il difetto che larticolo Harness-R1 documenta, i modelli fissi propongono patch plausibili che peggiorano
* Fidarsi di una singola esecuzione delleval: serve la mediana su piu run, e anche cosi oggi non basta
; Prossimo passo :
; Prossimo passo :
* Costruire la sincronizzazione foglio->BigQuery del canon referenze che quella chat ha proposto invece di fare: foglio 58 righe contro BigQuery 47, divergevano in silenzio
* STABILIZZARE IL GIUDICE prima di ogni altra cosa: due giudici diversi con disaccordo in revisione, oppure criteri di valutazione deterministici sui casi doro (la risposta cita shot.py si o no, cita /vm/task si o no) invece di un giudizio libero
* Rimisurare eval_harness dopo la v7.9
* Solo dopo il giudice stabile il gate ha senso e la sentinella smette di dare falsi allarmi
* Restano 6 routing file
* Migrare i 289 script al gateway partendo dai 5 in cron
 
=== migrazione-aigw ===
''Aggiornato 2026-08-12 08:08 UTC'' — dominio: infrastruttura AI / gateway
 
; Obiettivo : Far passare TUTTI i client AI dal gateway aigw, per avere log e cost guard inaggirabili, e poi ruotare le chiavi provider
; Fatto (con prova) :
* VERIFICATO che il gateway aigw esiste ed e reale: systemd active su translator, /opt/aigw/aigw.py, calls.jsonl con 7 chiamate vere loggate fra cui oracolo-agent su glm-5.2 e client cc su deepseek-chat, con token in/out e costo
* LANCIATO in asincrono il censimento che mancava: job censimento_aigw, scripts/censimento_aigw.py. Cerca su VM, translator e media quali script usano ancora sk-or-v1, api.deepseek.com, openrouter.ai, dashscope, moonshot direttamente invece del gateway. Sola lettura, nessuna modifica. Esito in gs state/migrazione_aigw.json
* CHIUSO UN BUCO in chiusura.py: la regex dei rinvii copriva nella prossima sessione al singolare ma non nelle prossime sessioni al plurale, ne progressivamente, man mano, a tappe. Aggiunto anche il gruppo CODA: la coda della, li migro, restano da fare. Provato sul testo reale: ora pesca tutti e tre i punti piu la mancanza del contratto
; Provato ed escluso :
* Migrare gli script automaticamente senza prima censirli: circa 14 sul VM era una stima, non una lista. Il censimento produce la lista vera con quali girano da cron
* Ruotare le chiavi provider prima che lultimo client sia migrato: spacca i non migrati
; Prossimo passo :
* Leggere lesito di censimento_aigw e migrare per priorita, partendo dagli script in cron
* Hermes: config non trovata al primo giro, va cercata
* Solo a migrazione completa ruotare le chiavi provider: da quel momento la policy e fisicamente inaggirabile
 
=== finanze-classificazione ===
''Aggiornato 2026-08-11 15:08 UTC'' — dominio: contabilita / finance
 
; Obiettivo : Chiudere il buco DA_CLASSIFICARE e impedire che il lavoro venga azzerato ogni notte
; Fatto (con prova) :
* CREATO routing file FINANZE.md, su Drive id 176Tw19NgXPszcTEtPJEgbrjT00iD2a7i, verificato 4.696 byte
* CENSITO cosa esiste gia in isicnv_finance: 105 tabelle e 19 viste, fra cui v_costi_per_categoria, v_spese_azienda, v_spese_aziendali_da_conto_personale, v_finance_quinquennale, v_riconciliazione_allievi
* TROVATA la causa vera del blocco: classification_rules ha 678 regole agganciate al campo counterparty, ma controparte_nome e NULL su TUTTE le 8.389 righe DA_CLASSIFICARE. Le regole non possono agganciare nulla
* MISURATO: derivando la controparte con TRIM(IF(direction=OUT, dst_name, src_name)) si classificano subito 3.413 movimenti pari a 666.086 euro, il 38 per cento, senza scrivere una regola nuova
* Stato attuale: DA_CLASSIFICARE 8.389 mov / 1.743.096 eur, DA_CHIARIRE 98 mov / 200.025 eur
* ESEGUITO. Backup transactions_multianno_bak_20260809 (14.492 righe)
* controparte_nome popolato su tutte le 8.389 righe da src_name/dst_name secondo direction
* Applicate le 678 regole di classification_rules: 3.413 movimenti classificati, DA_CLASSIFICARE sceso da 8.389 a 4.976 movimenti e da 1.743.096 a 1.077.010 euro. Marcati con classifier_blob auto:classification_rules:20260810
* Categorie assegnate: INCOME_CORSI 1.116 mov 472.134 eur, PERSONAL 431, BIZ_FOR_UNIVERSITE 197, PERSONAL_GENUINE 404, MARKETING 96, CASH 57, ANNA_FAMILY 76, REVIEW 353, TRASPORTI 166, STAFF 33, TRAVEL 40, TECH 353, LEGAL 12, INTERCOMPANY 13
* INTEGRITA VERIFICATA: 14.492 righe prima e dopo, somma importi 4.351.207 identica
* REGOLE DI MARCO INSERITE in classification_rules e applicate: LIGHTNING SOURCE -> INCOME_LIBRI (royalties, e IN non OUT: sono ricavi non costi di stampa), Di Feo Gioacchino -> INCOME_CORSI VIP COURS, Alena Telezin -> INCOME_CORSI corso Svizzera, IPCA -> INTERCOMPANY collaborazione associazione italiana, To GBP e To EUR -> FX conversioni interne Wise
* Assegnati: FX 50 mov 51.572 eur, INCOME_CORSI 7 mov 41.750, INCOME_LIBRI 3 mov 24.965, INTERCOMPANY 9 mov 20.000
* RESIDUO ora 4.907 mov / 938.723 eur (partenza 8.389 / 1.743.096)
* INDAGINE sui 113 (da identificare): tutti IN su Universite apr-lug 2026, causali loan 15.050, vuota 8.374, Wages 7.094, bonus, rimborsi progetto, May Rent, fatture, Saldo corso Roma, quote iscrizione
* Gmail isicnv interrogabile via token-any-isicnv: le notifiche Wise Denaro ricevuto da X contengono il nome mancante. Estratte 12 mail con nome (TODARO STEFANIA, MORRONI CRISTIANA, Giuseppe Giudice, BERTON LINE SRL, Daniele Pacioni, D ALONZO ELISA, PRIVITERA ANTONINO, DONATI NAZZARENO...) in /home/claudeuser/wise_mail_match.json
* FALSO SUCCESSO SCOPERTO: tutto il lavoro di classificazione del 10 agosto (3.413 movimenti miei piu circa 1.700 di unaltra chat) era stato AZZERATO. DA_CLASSIFICARE era tornato a 8.389 mov / 1.743.096 euro, il numero esatto di partenza, mentre i marcatori in classifier_blob restavano a dire che il lavoro era stato fatto
* CAUSA TROVATA: finance_daily_sync.py alle 06:45 ha un passo chiamato classificazione che riscrive la colonna category da zero e riporta a DA_CLASSIFICARE tutto cio che le sue regole interne non riconoscono. Confermato da INFORMATION_SCHEMA.JOBS_BY_USER: catena di UPDATE alle 06:49-06:51 su category e perimetro, e ultima modifica tabella alle 06:50:29
* RIMEDIO: creato scripts/riapplica_regole.py, in cron alle 07:10 (dopo il sync). Ripopola controparte_nome e riapplica classification_rules
* BUG TROVATO NEL RIMEDIO: dopo le 6 regole aggiunte ieri alcune controparti erano doppie e BigQuery rifiutava con UPDATE must match at most one source row. Aggiunta deduplica con ROW_NUMBER sulla piu recente
* RIPRISTINO ESEGUITO: da 8.389 a 4.646 movimenti, da 1.743.096 a 702.043 euro
* USATA la libreria google.cloud.bigquery al posto della CLI bq: la CLI perdeva le regex nei livelli di escaping e l UPDATE tornava False senza errore visibile
* la libreria restituisce num_dml_affected_rows
; Provato ed escluso :
* Riclassificare a mano controparte per controparte come proponeva laltra chat: e lavoro gia fatto, 678 regole esistono. Il problema non erano le regole ma il campo vuoto
* Fidarsi dei nomi di colonna italiani: il ledger usa date amount_src category description NON data importo categoria
* Scrivere il marcatore nel campo note: e FLOAT64 non STRING, lUPDATE fallisce. Usare classifier_blob che e STRING
* Riclassificare a mano controparte per controparte prima di aver popolato controparte_nome
* Recuperare i nomi dai dati grezzi: recent_2026_raw ha sender valorizzato solo su 19 righe su 334 nel periodo, merchant zero. Il nome NON e nei grezzi
* Il campo note e FLOAT64: usare classifier_blob per i marcatori
* Solo 12 notifiche Wise nel periodo contro 113 movimenti: la posta copre una minoranza dei casi
* Modificare la logica interna del passo classificazione del sync: rischioso e non necessario. Meglio un passo additivo dopo, che riapplica la fonte di verita classification_rules
* Fidarsi di un ESITO FATTO senza ricontrollare il giorno dopo: era vero quando scritto e falso dodici ore dopo
* Stringhe SQL con apostrofo (Spese per l ufficio): usare ScalarQueryParameter
; Prossimo passo :
* Aggiungere alla sentinella notturna il controllo che DA_CLASSIFICARE non risalga


=== referenze-canon ===
=== referenze-canon ===
Estratto da "https://wiki.marcoparet.com/wiki/Cantieri_aperti"