Cantieri aperti: differenze tra le versioni
| [versione verificata] | [versione verificata] |
handoff automatico |
handoff automatico |
||
| Riga 288: | Riga 288: | ||
* Correggere reindex_full.sh perche non svuoti il flag delle righe aggiunte durante lesecuzione | * Correggere reindex_full.sh perche non svuoti il flag delle righe aggiunte durante lesecuzione | ||
* Rifare il task programmato ChatGPT: ora /vm/task funziona, ma job.py resta preferibile | * Rifare il task programmato ChatGPT: ora /vm/task funziona, ma job.py resta preferibile | ||
== Chiusi == | |||
=== propensity-scoring-allievi === | |||
''Aggiornato 2026-08-12 10:54 UTC'' — dominio: BigQuery / dati | |||
; Obiettivo : Lead scoring predittivo: colonna propensity_allievo in contatti_master, job notturno | |||
; Vincoli in vigore : | |||
* MERGE tocca solo colonne propensity | |||
* MERGE a lotti annuali (limite 4000 partizioni) | |||
* score relativo non calibrato | |||
; Fatto (con prova) : | |||
* Benchmark TabICL 0.9727 vs XGBoost 0.9623 | |||
* script propensity_allievo.py | |||
* primo run 251550 righe in 229s | |||
* cron 05:15 | |||
* wiki + learnings + memoria | |||
; Provato ed escluso : | |||
* TabICL in produzione (22s/849 righe su CPU, OOM con default su 3.9GB) | |||
* /vm/task (runner CLI non autenticata) | |||
; Prossimo passo : | |||
* niente - chiuso. Opzionali: fix /vm/task, calibrazione score, sheet settimanale Ilaria | |||
[[Categoria:Domini operativi]] | [[Categoria:Domini operativi]] | ||
Versione delle 10:54, 12 ago 2026
Pagina generata automaticamente da handoff.py. Non modificare a mano: le modifiche vengono sovrascritte.
Ogni cantiere e' lo stato di un lavoro in corso, scritto durante la sessione e non alla fine. Chi riparte legge: HARNESS + il routing file del dominio + il cantiere. Nient'altro.
Cantieri attivi
harness-standard
Aggiornato 2026-08-12 09:22 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
- Vincoli in vigore
- La gerarchia deve SOSTITUIRE substrati esistenti, mai affiancarsi: oggi ne esistono 7 paralleli
- Ogni routing file ha 6 sezioni fisse: chi esegue / accessi / come si verifica / criterio di accettazione / fallimenti noti / strumenti ammessi
- Nessuna credenziale nei routing file, solo puntatori
- Fatto (con prova)
- Analizzato export completo Claude di marcoparet@gmail.com: 614 conversazioni, 26.921 messaggi, 55,8M caratteri (file su VM /home/claudeuser/claude_export/analysis/)
- Misurato: attrito piatto sulla lunghezza della chat (14-18 per 100 msg in ogni fascia) = problema strutturale non di contesto
- Misurato: autocorrezioni Claude raddoppiano oltre 25-50k token di contesto (8,8 -> 17,2 per 100 msg) = context rot reale, ginocchio a 25-50k
- Misurato: 899 route nel bucket, 525 MAI citate in nessuna chat, ~25 reggono il sistema
- Misurato: 8 domini coprono il traffico (spedizioni 190 chat, VM 155, BQ 151, hosting 118, token 114, route 77, drive 76, wiki 59)
- Scritti HARNESS.md (1 pagina) e INFRA-VM.md (primo routing file compilato)
- Creato handoff.py su VM + pagina wiki Cantieri aperti
- MASTER READ ORDER v7.1 scritto: 1 pagina, 3 regole, tabella routing 8 domini, STEP cantieri, STEP handoff, STEP asincronia, Appendice A per modelli non-Claude
- INFRA-VM.md primo routing file compilato su 6 sezioni fisse
- handoff.py operativo su VM (GCS + wiki + memoria CC in una chiamata), testato write/resume/list
- Pagina wiki Cantieri aperti creata e verificata via getText.php
- MISURATO tassa di interruzione: 34,3 pc dei messaggi Claude chiede a Marco di decidere, 17,1 pc di eseguire a mano, sincrono/asincrono 4,2:1, turni di sola continuazione solo 2,7 pc (sintomo non causa)
- v7.1 APPESA sul canonico Drive 1Iyxrr5 (ok:true) — la v6.3 e superata
- BUG RISOLTO: browser_service.js su :8081 vuole POST con secret, il GET ?url= documentato per mesi era sbagliato: per questo la verifica headless falliva in silenzio. Creato scripts/shot.py, testato su wiki Cantieri aperti (149 KB, titolo corretto)
- Creato gs://isicnv-command-center-routes/TOKENS_STATUS.json = fonte di verita su token vivi/morti/non-Google
- Creato state/routes_inventory.json: 525 route su 899 mai citate in chat
- Harvest memoria per 5 dei 7 routing file in /home/claudeuser/routing_src/
- DRIVE ALLINEATO: canonico 1Iyxrr5 rinominato v7.1, intestazione in cima che punta alla versione corrente, v7.1 appesa in fondo (122.869 car, verificato)
- Caricato .txt v7.1 su Drive id 1TzhV-dMUTpXnGdwbxmxvk3iV9RR0ZVME nella cartella 1VQLc638
- Marcati SUPERATO i .txt v6_3 e v6_4 (rinominati, non cancellati)
- SCOPERTA v6.4 del 09/07 mai citata nelle regole (che dicevano v6.3): conteneva DUE serie di regole con gli stessi numeri (due R45, due R46, due R47) — la numerazione si era scontrata con se stessa
- BUG CRITICO TROVATO: /vm/task NON esegue bash. Passa la stringa alla CLI Claude Code sulla VM, che e scollegata (Not logged in). Restituisce status DONE in 5 secondi SENZA eseguire nulla (verificato: /tmp/t_start non creato). Inoltre il parametro si chiama task non cmd: chi usa cmd prende error task required
- SOSTITUTO CREATO E VERIFICATO: /home/claudeuser/scripts/job.py --run/--status/--log/--list, nohup con sessione staccata. Test reale: job da 140 secondi, rc=0, timestamp /tmp/j_start e /tmp/j_end confermano la durata
- MASTER v7.2 pubblicata su Drive (canonico rinominato, intestazione, txt id 1ptmfkfwlsqZWvV3LrS77guhF251U7FAr), v7.1 marcata SUPERATO
- AUDIT ROUTE ESEGUITO (22 route, una per una, con verifica effetto reale, lanciato via job.py in 111s): 8 REALI, 10 FORMA, 1 ERRORE, 1 FALSO_OK, 2 saltate perche distruttive. Rapporto gs://isicnv-command-center-routes/state/route_audit_AUDIT1786141034.json
- UNICO falso successo confermato: /vm/task
- SCOPERTO /bq/query vuole {sql} NON {query}: stessa famiglia del bug /vm/task (task non cmd). Prima di dire che una route e rotta, controllare il nome del parametro
- SCOPERTO /cc/check riporta http_vm ERR fetch failed come esito normale (Cloud Run non ha TCP diretto verso VM): allarme falso, ignorare quella riga
- SCOPERTO incoerenza conteggi memoria: /memory/list dice 1000, /memory/search dice 2822 indicizzati
- SCOPERTO sheet STATE 1KRoCu ha #ERROR! nella riga di intestazione
- MASTER v7.3 pubblicata su Drive, txt id 1HQKcSHCr1uPHbCvae94DITcSgWs0AV7a
- VERIFICA TOTALE eseguita con script verify_all.py via job.py: 24 controlli su 24 PASS al secondo giro. Primo giro 4 FAIL, tutti corretti
- ERRORE MIO TROVATO E CORRETTO: il .txt v7.3 caricato su Drive conteneva in realta la v7.2, per un replace v7.2->v7.3 che non catturava v7_2 con underscore. Vero v7.3 ora su Drive id 1-noo7YFS-gzhidiWO0fJzLW7rxL-VTUQ (12.955 byte)
- ERRORE MIO TROVATO E CORRETTO: INFRA-VM.md era citato nel Master ma non esisteva in nessun posto durevole, solo come allegato di chat. Ora su Drive id 1Y6ZUeoQnK514ob5-3iiR0qMYZBD_kQPJ
- BUG NUOVO: /memory/search riporta total_indexed instabile fra chiamate successive (2821, 2822, 1932). L indice non e deterministico
- EVAL HARNESS COSTRUITO: /home/claudeuser/scripts/eval_harness.py. Metodo: 6 casi doro derivati da fallimenti reali del 07/08, modello candidato DeepSeek legge il Master e dice cosa farebbe, giudice indipendente Kimi K2 valuta la TRAIETTORIA non la prosa
- PRIMO GIRO 2/6. Corretto STEP 2 del Master (--list SEGUITO da --resume, obbligatorio) -> v7.4 pubblicata
- SECONDO GIRO 5/6. Ciclo misura-correggi-rimisura funzionante
- SCOPERTA CRITICA: il giudice NON e affidabile. Primo giro ha bocciato job_lungo per uso del path assoluto (risposta in realta perfetta)
- secondo giro ha bocciato verifica_pagina che al primo giro aveva promosso, a documento invariato su quel punto. Instabilita del giudice fra run identiche
- FILTRO ANTI-INTERRUZIONE creato: /home/claudeuser/scripts/continua.py. Si chiama nellistante in cui si starebbe per porre una domanda a Marco. Restituisce CONTINUA (con la scelta gia presa) o CHIEDI. NON PUO BLOCCARE: puo solo togliere interruzioni, quindi un errore nel senso CHIEDI riporta solo al comportamento di prima
- Architettura a due stadi: cancello deterministico a costo zero sulle tre eccezioni (pagamenti, serve Marco fisicamente, azioni irreversibili), modello DeepSeek solo sui casi ambigui
- BACKTEST su 120 domande storiche vere estratte dallexport (5.443 totali trovate): 80,8 pc sarebbero state auto-continuate, 19,2 pc restano a Marco. 5 casi su 120 fermati dal cancello deterministico senza chiamare il modello
- MASTER v7.5 pubblicata, contenuto VERIFICATO su canonico e su txt (14.633 byte, continua.py presente in entrambi)
- TERZO FILTRO CREATO: /home/claudeuser/scripts/resta.py, anti-menu. Complementare a continua.py: quello intercetta le DOMANDE, questo intercetta i MENU, cioe le voci messe sotto RESTA che lassistente poteva eseguire
- Novita rispetto a continua.py: confronta ogni voce con le ISTRUZIONI ricevute. Se la voce ricalca cio che Marco aveva gia chiesto, non e un residuo, e il compito
- Tre schemi riconosciuti a costo zero: se vuoi/posso anche/quando vuoi = offerta travestita da domanda
- domani/prossima sessione = rinvio da programmare
- stesso trattamento per X = procedura collaudata
- Provato sui casi veri dello screenshot Marco: Lettura sistematica TIF marchi e Deed di Ivinghoe entrambi ESEGUI deterministico, costo zero
- BACKTEST su 34 voci RESTA storiche: 58,8 pc andava eseguito. Campione piccolo perche il formato RESTA e convenzione recente
- BUG CORRETTO: il modello puo restituire meno voci di quelle chieste, causava list index out of range. Ora indice validato
- MASTER v7.6 pubblicata, contenuto verificato su canonico e txt id 1TsnwTE2JIQYQLTR3pxdf6xhujGsfMIB_
- SENTINELLA NOTTURNA installata: scripts/notte.py in cron alle 03:20 con flock. Gira eval_harness, verify_all, e 8 controlli di salute
- confronta con lo stato di ieri su gs state/sentinella.json
- avvisa su Telegram SOLO se qualcosa peggiora. Silenzio uguale tutto a posto
- PRIMA ESECUZIONE ha trovato subito 4 cose: disco VM al 93 per cento, guard OpenRouter TRIPPED, 6 token morti, 1 FAIL in verify_all
- DISCO: liberati 5,8 GB, da 93 a 82 per cento. Rimossi conversations.json 853MB (copia su Drive resta), ocr_in, file /tmp oltre 2 giorni, log ruotati oltre 14 giorni. Tenuta la cartella analysis (660KB)
- GUARD OPENROUTER RIARMATO: era TRIPPED dal 28 luglio, tredici giorni. Si riarma cancellando openrouter_guard.state. Backup in .disarmato_20260810. Ora daily 1.620 cap 3.00 over False tripped False
- MASTER v7.7 con STEP 5-D DOMANDA INVERSA: fare e offrire di disfare invece di chiedere il permesso. Pubblicata e verificata, txt id 1pp4jbcz1_x06I94jnGN_Y8dTNRqgTkC2
- DIFETTO DEL MIO FORMATO CORRETTO. Il contratto ESITO/PROVA/RESTA invitava a riempire RESTA anche quando niente era bloccato: una chat ha scritto RESTA niente di bloccato e poi ha elencato il lavoro. Contraddizione in due righe
- MASTER v7.8: aggiunto il campo IN CORSO. RESTA accoglie SOLO i bloccanti, il lavoro non bloccato va lanciato con job.py PRIMA di rispondere. Pubblicata e verificata, txt id 1hhlScUiQLd1ySQ7GQDouVDVa29e_CeUT
- resta.py ora rileva la CONTRADDIZIONE: lista RESTA non vuota con zero bloccanti, e propone i comandi job.py da lanciare
- TRE FALSI POSITIVI MIEI CORRETTI durante il test: la regex bloccava qualsiasi voce contenente un importo (citare 21.236 EUR non e spenderli)
- il prompt del modello faceva lo stesso errore
- un bug di quoting rompeva la sintassi
- VERIFICATO Qwen3.8-Max: esiste davvero, annunciato 2 agosto 2026, 2,4T parametri, disponibile su OpenRouter come qwen/qwen3.8-max con 1M di contesto a 2 dollari per milione in ingresso e 6 in uscita
- Il dato dei 16 giorni NON risulta: la cifra documentata e 35 ore di esecuzione autonoma, 432 valutazioni di kernel, 1.158 chiamate a strumenti. Cera anche un compito simulato di un anno, ma e simulazione non tempo reale
- TESTATO sul nostro eval harness come candidato al posto di DeepSeek
- BUG TROVATO E CORRETTO in eval_harness: Qwen mette il testo nel campo reasoning e lascia content vuoto, il lettore restituiva None. Ora legge content poi reasoning poi reasoning_content. Corretto in entrambi gli script
- Osservazione dalla rassegna del lancio, coerente con il nostro lavoro: la capacita di lungo orizzonte e una proprieta del modello PER limbracatura, non del modello da solo. I fallimenti si dividono in deriva dallobiettivo, corruzione del contesto, azioni irreversibili
- TERZO BUCO CHIUSO. Una chat ha finito con Ora ho tutto per costruire il blocco credenziali e con Conviene che la sincronizzazione diventi automatica: non e una domanda (continua.py non la vede) e non e una lista RESTA (resta.py non la vede). Passava indenne
- CREATO scripts/chiusura.py: controllo sul MESSAGGIO INTERO prima di mandarlo. Riconosce dichiarazioni di prontezza (ora ho tutto per, posso procedere, il prossimo passo e, non resta che, sono pronto a), proposte di automazione (conviene che, andrebbe reso automatico, si potrebbe), rinvii (domani, quando vuoi), domande residue, e la mancanza del contratto ESITO/PROVA/IN CORSO/RESTA
- PROVATO sul testo reale ricevuto da Marco: pesca entrambi i punti piu la mancanza del contratto. Verdetto RIVEDI
- 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
- 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
- GIUDICE STABILIZZATO: creato scripts/eval_det.py con criteri deterministici per parole chiave al posto del giudice LLM. Ogni caso doro ha un elenco DEVE e un elenco NON DEVE verificabili: shot.py presente, /vm/task assente, sql e non query, handoff.py con --list e --resume, scelgo/procedo senza chiedere a Marco. Costo del giudizio: zero
- VARIANZA AZZERATA: v7.9 misurata 5 e 5, dove il giudice LLM sullo stesso documento dava 5, 2, 4
- RIMISURATO TUTTO con il metro stabile: v7.6 mediana 5.5, v7.7 mediana 5.5, v7.9 mediana 5.0. Le differenze restano dentro 1 punto: nessuna delle versioni si distingue davvero dalle altre
- QWEN 3.8-MAX su v7.9: 5 e 5, mediana 5.0, IDENTICO a DeepSeek. Il confronto precedente Qwen 3/6 contro DeepSeek 4/6 era interamente rumore del giudice
- Il caso che fallisce sistematicamente e scelta_domanda: il modello descrive invece di scegliere ed eseguire
- BATTITO E GUARDIANO costruiti su proposta di Marco. scripts/battito.py: una sessione scrive lo stato completo a intervalli, con il COMANDO ESATTO da eseguire dopo. scripts/guardiano_battito.py in cron ogni 2 minuti: se un battito non arriva da 5 minuti e il lavoro non e chiuso, esegue quel comando e avvisa su Telegram
- VARIANTE DI SICUREZZA rispetto alla proposta: il guardiano NON fa leggere il log a un modello che decide. Esegue solo il comando gia registrato dalla sessione. Nessun modello nel ciclo, quindi nessuna deriva e nessun comando inventato
- Altre sicurezze: massimo 6 ripartenze per lavoro, pausa 10 minuti fra due ripartenze, rispetto del cost guard OpenRouter, avviso Telegram a ogni ripresa
- PROVA END-TO-END SUPERATA: battito invecchiato di 9 minuti, guardiano ha rilevato la chat ferma, eseguito il comando, file /tmp/ripresa_ok.txt creato davvero, Telegram inviato
- La prima prova era fallita correttamente: cost guard TRIPPED, non e ripartito. La sicurezza ha funzionato prima ancora della funzione
- GUARD OPENROUTER era di nuovo TRIPPED da ieri sera 20:15 con spesa gia rientrata (1.243 su cap 3.00): riarmato, backup in .bak_20260812
- PIANO NUMERATO costruito su proposta di Marco: scripts/piano.py. Si scrive una volta allinizio, quando il contesto e pulito. Ogni punto porta il comando che lo esegue. --fatto N chiude un punto, --prossimo restituisce il comando del primo punto ancora aperto
- GUARDIANO COLLEGATO AL PIANO: se un battito si ferma e esiste un piano, esegue il PROSSIMO PUNTO APERTO invece del comando generico di fallback
- PROVA SUL CASO DI MARCO: piano di 5 punti, chat ferma dopo il punto 3. Il guardiano ha eseguito il PUNTO 4, non il fallback. Verificato: /tmp/piano_test.log contiene PUNTO4_ESEGUITO. Messaggio Telegram con il numero e la descrizione del punto
- BUG CORRETTO nella patch: avevo aggiunto un segnaposto nel messaggio senza il valore, TypeError sulla formattazione. Il comando era stato eseguito lo stesso, ma lavviso non partiva
- Il trio ora si compone: PIANO dice cosa fare e in che ordine, BATTITO dice fin dove si e arrivati, GUARDIANO riprende dal primo punto aperto
- Provato ed escluso
- Adottare ahar / agentharnesses-cli: presuppone Claude Code su repo locale, Marco lavora da smartphone via route CC
- Ridurre la lunghezza delle chat come rimedio: i dati mostrano che non e la lunghezza il problema
- Marcatore regex bloccato per misurare Claude in difficolta: falsi positivi pesanti (denaro bloccato, siti bloccati AGCOM)
- La cartella Drive 1TpajgASPSO non e accessibile da nessun account: 404 su tutti i token
- Creare un nome nuovo tipo HARNESS.md accanto al Master: errore, aggiungeva un substrato invece di sostituirlo. Il nome resta MASTER READ ORDER
- Ridurre i turni continua come rimedio: sono il 2,7 pc, il costo vero sono le domande di Claude
- Spostare subito le 525 route in routes_deprecated: mai citata in chat NON significa mai usata, possono esserci chiamanti cron o altre route. Prima cercare i chiamanti
- Rinominare o cancellare i token morti: si rompe chi li referenzia. Meglio TOKENS_STATUS.json come fonte di verita, senza toccare i file
- Cancellare i vecchi .txt: rinominati SUPERATO, reversibile
- Riscrivere il canonico da zero: e append-only per tracciabilita, si aggiunge intestazione in cima
- Rifare il login della CLI Claude Code sulla VM per riparare /vm/task: richiede OAuth interattivo di Marco, e job.py risolve senza dipendenze
- Fidarsi della documentazione delle route senza provarle: due bug su due (headless GET, vm/task) erano documentati male
- Testare /vm/reset e /routes/deploy: distruttive, saltate di proposito
- Cancellare i record di prova via /memory/delete: la route NON ESISTE (Cannot POST). Restano da ripulire test_1786141053523_gbv40d e system_state_1786092629694_7idl9o
- Fidarsi di un upload senza rileggere il file caricato: il nome era giusto ma il contenuto no. La verifica deve confrontare il CONTENUTO, non solo lo status 200
- Usare un modello giudice come CANCELLO di autorizzazione a procedere: produce falsi FAIL, quindi bloccherebbe lavoro corretto. Va usato come valutatore aggregato su golden set, con revisione umana dei numeri, non come autorita per singola decisione
- Giudice con potere di bloccare: produce falsi FAIL e blocca lavoro corretto. Marco ha corretto il disegno: il giudice puo solo TOGLIERE interruzioni, mai aggiungerne. Con questa asimmetria non esiste caso in cui peggiori le cose
- Un giudice esterno con potere di bloccare: tutti e tre i filtri (continua, resta, e leval) seguono la stessa asimmetria, possono solo TOGLIERE interruzioni
- Innescare lescalation sul numero di passaggi: non distingue progresso da stallo. Il segnale giusto e ripetizione senza cambio di stato
- Segnalare a Marco i problemi trovati invece di risolverli: e la domanda inversa. Si fa, si lascia una via di ritorno (backup, rinomina, .disarmato) e si offre di disfare
- Cancellare senza backup: ogni intervento di oggi e reversibile
- Bloccare una voce solo perche contiene una cifra: analizzare importi grandi costa zero e va eseguito. La soglia dei 2 euro riguarda quanto costa ESEGUIRE lazione, non le cifre nominate
- Adottare Qwen come esecutore senza misurarlo: il test sui 6 casi doro e la via
- 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
- 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
- Il giudice LLM come strumento di misura: varianza 3 punti su 6 sullo stesso input, inutilizzabile per un gate
- Le tre conclusioni basate su di lui: v7.7 peggiorata (falso), Qwen inferiore a DeepSeek (falso), differenze fra versioni del Master (non dimostrate)
- Far decidere a un modello cosa eseguire alla ripresa: e la strada al loop infinito e al danno non sorvegliato. Il comando lo scrive la sessione quando e lucida, il guardiano lo esegue e basta
- Riarmo automatico del cost guard: resta manuale di proposito, ma la sentinella ora lo segnala
- Far dedurre a un modello quale sia il prossimo punto: il piano lo dice in modo deterministico. Nessun modello nel ciclo di ripresa
- Prossimo passo
- Aggiungere piano.py e battito.py al Master come STEP di apertura e di avanzamento lavoro
- Agganciare gate_master.py e la sentinella a eval_det.py
- Rendere piu operativa la regola C: scelta_domanda fallisce con tutti i modelli
- Migrare i 289 script al gateway partendo dai 5 in cron, usando il piano numerato come banco di prova reale
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
Aggiornato 2026-08-10 20:26 UTC — dominio: Referenze E-E-A-T
- Obiettivo
- VIA eseguito: pubblicazione dossier referenze
- Fatto (con prova)
- 3 tabelle BQ (canon 31, libri 12, citazioni 30)
- 3 pagine rassegna LIVE su neurolinguistic.com/referenze/rassegna/ (lastampa-2002, autostima-ipnosi-shock, donnad) con screenshot-verify OK
- job wayback_rassegna programmato +4h con retry
- NGH/NFNLP/ministero-psicoterapeuti/sindacato-FR integrati in pagina+llms+canon
- GCS docs/referenze/ sincronizzato
- Sheet 1COwn3BXgkzFmKTujVimzCX_X5P_1Q1a_uL2CfEt27oM con 3 tab
- canon 43 righe
- scoperta portfolio marchi (EMDR=EMF di Marco, TimeLine, Ipnorapport, visura 1996)
- Ivinghoe registrata subordinata ad Anneville
- LIVE verificati con shot e vista: /referenze-marco-paret/ entity home con Australia+Pandiscia integrate
- /llms.txt con backup del precedente su GCS llms_backup_pre_referenze.txt
- /referenze/ con 4 PDF: apca, uibm-1999 redatto con CF e indirizzi coperti verifica visiva OK, oradea-2024 redatto 3 box, sinape-2025. Wayback in coda Hetzner +1h. Canon stati aggiornati a pubblicato
- Provato ed escluso
- stampa2=duplicato La Stampa
- Eminen Stell non finanziata
- Marie Claire non trovata
- pirateria Scribd+forum RU segnalata
- duplicati byte-identici nei TIF marchi
- deed Ivinghoe NON trovato in Drive ne foglio, stato da_documentare
- llms sugli altri 4 domini non ancora
- Prossimo passo
- 1 llms.txt su marcoparet.com .net mesmerismus mesmerismonline da access_howto
- 2 blocco head 244 pagine RAIDA
- 3 leggere log Hetzner wb_retry e gb
- 4 TIF marchi estrazione
- 5 rigenerare Sheet dal canon
cairn-archive
Aggiornato 2026-08-10 15:58 UTC — dominio: Referenze E-E-A-T / neurolinguistic.com
- Obiettivo
- Sezione archivio storico CAIRN su neurolinguistic.com secondo il Doc AI Website Build Instructions + protocollo backward audit
- Vincoli in vigore
- ogni claim mappato a un Archive ID di CAIRN_archive e a una riga di CAIRN_backward_audit
- niente riga di cautela su Art.30 in pagina (decisione Marco 10/08)
- planned != held
- mail solo redatte
- Fatto (con prova)
- aggiunta riga CAIRN-2012-AVALON a CAIRN_archive
- nota interna su AUD-001 col.N
- llms.txt e sitemap-static.xml aggiornati (11 url)
- Provato ed escluso
- archive.org/wayback/available da 429: usare la CDX API con retry
- Prossimo passo
- salvare capture fresche su Wayback (Save Page Now) delle 11 nuove pagine
- facsimili redatti delle 3 mail
- cercare flyer/foto per le mostre thangka a Nizza (oggi solo testimonianza orale)
- valutare pagina EN/IT bilingue
oracolo-reindex
Aggiornato 2026-08-09 09:02 UTC — dominio: Biblioteca Magnetica / Oracolo
- Obiettivo
- Reindicizzare la coda Biblioteca, ingerire il Traite dOr, e riparare /vm/task
- Fatto (con prova)
- DIAGNOSI del fallimento del task programmato ChatGPT Archive Reindex: lerrore --dangerously-skip-permissions cannot be used with root/sudo NON e SSH ne Hetzner, e un messaggio della CLI Claude Code. Lo strumento Command Center VM passa da /vm/task che gira la stringa alla CLI claude come root, che rifiuta il flag ed esce. Stesso bug documentato il 07/08
- Flag deep_archive_new.flag fermo dal 19-21 luglio con 27 documenti mai reindicizzati
- VM in fetch failed: recuperata con la sequenza documentata status/reset/90s
- Reindex lanciato con job.py id reindex_oracle, flock su Hetzner
- Traite dOr trascritto e INSERITO in biblioteca.corpus doc_id DEEP_4616b9112532634b71f1, 13.363 caratteri, lingua fr, tier extended, verificato con query BQ. Flag ora a 28 righe
- BUG /vm/task RISOLTO alla radice. La route statica invoca claude --dangerously-skip-permissions -p COMANDO
- la CLI rifiuta il flag da root. Installato wrapper /usr/local/bin/claude che riconosce quello schema ed esegue con bash, e stampa nel log cosa e successo e cosa usare per i job lunghi. CLI vera spostata in claude.real. VERIFICATO: task di prova ha creato davvero /tmp/fix_test.txt
- Reindex 1 completato in 20 minuti (job reindex_oracle DONE rc=0)
- SCOPERTA RACE CONDITION: il documento inserito DURANTE il reindex e stato svuotato dal flag senza essere indicizzato. Verificato con ricerca BM25 su Hetzner: Fresse-Louis non trovato. Ri-flaggato e rilanciato job reindex_traite
- SCOPERTO limite ~100KB del body di /vm/exec-direct (default Express), fallimento muto con ok:false e stderr vuoto
- Provato ed escluso
- Trasferire le foto alla VM per OCR tesseract: /vm/exec-direct rifiuta payload sopra ~100KB e fallisce IN SILENZIO (ok:false, stderr vuoto). Falliti 3 tentativi: base64 intero, compresso, a blocchi. Strategia cambiata: trascrizione lato Claude e trasferimento del solo testo
- Programmare il reindex via /vm/task: e la causa del guasto, va sostituito con job.py o cron
- Route /gcs-upload-url per firmare URL di scrittura: creata ma il service account Cloud Run non ha iam.serviceAccounts.signBlob. Va rimossa o va concesso il permesso
- Trasferire immagini via exec-direct: sopra 90KB fallisce muto. La via giusta per i libri e caricarli nella cartella Drive della Biblioteca e usare biblioteca/ingest.py, che gestisce gia scarico e coda OCR tesseract
- Prossimo passo
- Verificare che dopo reindex_traite il documento sia cercabile via BM25 su Hetzner porta 8085
- ATTENZIONE: guard OpenRouter su Hetzner e TRIPPED e richiede RIARMO MANUALE. Log dice soglie rientrate ma lo stato resta TRIPPED: daily 0.882, settimana 12.72, cap 3.00. Qualcosa e fermo da allora
- Rimuovere la route gcs-upload-url non funzionante
- Correggere reindex_full.sh perche non svuoti il flag delle righe aggiunte durante lesecuzione
- Rifare il task programmato ChatGPT: ora /vm/task funziona, ma job.py resta preferibile
Chiusi
propensity-scoring-allievi
Aggiornato 2026-08-12 10:54 UTC — dominio: BigQuery / dati
- Obiettivo
- Lead scoring predittivo: colonna propensity_allievo in contatti_master, job notturno
- Vincoli in vigore
- MERGE tocca solo colonne propensity
- MERGE a lotti annuali (limite 4000 partizioni)
- score relativo non calibrato
- Fatto (con prova)
- Benchmark TabICL 0.9727 vs XGBoost 0.9623
- script propensity_allievo.py
- primo run 251550 righe in 229s
- cron 05:15
- wiki + learnings + memoria
- Provato ed escluso
- TabICL in produzione (22s/849 righe su CPU, OOM con default su 3.9GB)
- /vm/task (runner CLI non autenticata)
- Prossimo passo
- niente - chiuso. Opzionali: fix /vm/task, calibrazione score, sheet settimanale Ilaria