Cantieri aperti

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

benchmark-visibilita-ai

Aggiornato 2026-08-16 13:48 UTC — dominio: ai-search

Obiettivo

MISURA INTERMEDIA: marcoparet.com gia' dominio top nelle citazioni AI; P8-P9-P10 risposti da Marco

Vincoli in vigore

• testo pubblico mai da Claude (watermark)
• citazioni solo con fonte completa e gate verbatim
• fonte sempre dichiarata in pagina

Fatto (con prova)

• v2 eseguito 12/08 1050 chiamate 4 errori: JSON /opt/wikibox/state/benchmark_ai_v2_20260812_1809.json + CSV summary. Controllo 100pct ovunque. Definizione: solo ipnosi_non_verbale 12/50 e fascinazione 7/50, tutte da Gemini. Mercato b1 quasi zero (1/315). Mercato b2 Perplexity: mesmerismus 4/5, fascinazione 3/5, resto 0. wiki.marcoparet.com e la fonte piu citata nei riferimenti. PT NON piu forte (0/70 mercato). Nessun concorrente commerciale: spazio occupato da YouTube/Wikipedia/Scribd/Udemy. Bug v1 corretto: mesmerismus come termine non conta piu come brand
• 13/08: regola watermark in memoria (rule_1786624124612_5qbv8r). oracle-cita riattivato+enabled su translator. tunnel-reranker systemd nuovo verso media 8089. cita_wiki.py deployato con gate verbatim (procedure_1786625083038_anqrlp). Report controllo per chat verifica: report in memoria CC. Estrazione 3 temi fascinazione in corso
• 13/08 sera: TRE PILLAR PUBBLICATI da Claude via SSH+WP-CLI FastComet (canale rollback.py). 197 ipnosi-non-verbale: replace blocco, live OK. 3576 guardarmi-negli-occhi: insert additivo, live OK. Mesmerismus: SCOPERTA slug duplicato - post 111 shadowed da PAGE 1582 che vince il permalink /blog/mesmerismus/
• blocco applicato ANCHE a page 1582 (backup pre_pillar_20260813_202256), live OK 3/3 sonde. Backup: ~/wikibox_backups/{197,3576,111,1582}/pre_pillar_20260813_*. Collaudo: 200, canonical self, nuovo contenuto presente, storico intatto. MCP CC testato vivo (tools/list ok): guasto ChatGPT era nella sua sessione connettore, non nel CC. Regola marchi aggiunta (Mesmerismus registrato, Luxmind commercio)
• 14/08: intervista Paret completata e ripulita (GDoc DEFINITIVA 122Py9-ftfDKmCo6Pbji73L3pmm1QKXCtwhvxNMgVV3A). Canone Meheust in memoria (canon_1786660725831_puth3n). 27 opere Meheust in BQ biblioteca.riferimenti_autori. BOZZA PILLAR generata da GLM-5.2 con brief completo (intervista+canone+6 citazioni verificate+polivagale+regole fattualita/fluido): 2442 parole, review Claude PASSATA (0 negazioni vietate). GDoc bozza: 1ZRR8JqKeFnfFQ3MpYw6aT8HqMG12nbU6AcfbXSoRT5c. GCS: drafts/paret-ai-pillars/bozza_fascinazione_v1.html. Nota: oracle-cita ora con Restart=always (override systemd)
• estrazione casi 0 valide (gate severo, temi da raffinare: Pigeaire, Husson)
• 14/08: v2 generata da GLM (2767 parole) con: esempi (ristorante, congresso+VIDEO zfIqe-WD4W0 embeddato, specchio/Virgilio, Di Pisa ipnosi istantanea da libro citabile), sezione Un mistero documentato: da Ficino a Donato (Ficino De amore, Agrippa, Della Porta, Meheust), lessico segreto/svelare qualificato (regola rule_1786691698743_ia8z1y + principio 18 RAIDA), 4 link interni. Review: 0 negazioni vietate. PUBBLICATA: post 11274, https://www.neurolinguistic.com/blog/fascinazione-ipnotica/ HTTP 200 canonical ok. Link in ingresso aggiunti da 1848 (il-potere-dellocchio) e 3576 (guardarmi-negli-occhi), backup pre_link_*. GCS: bozza v1+v2 in drafts/paret-ai-pillars/
• 14/08: intervista Marco (GDoc 1zfdcmJ7...) -> pillar generato GLM con 7 citazioni verificate (Guidi, Frere volonta causa prima, Joly), canone Meheust, parasimpatico/polivagale (parole di Marco: la vera sicurezza si appoggia al parasimpatico), segreto svelato (esci dai pensieri stai nel corpo), est modus in rebus, video passi magnetici eysSdCL7S1Q, tipografia inline, FAQ salute. PUBBLICATO post 11285 https://www.neurolinguistic.com/blog/magnetismo-personale/ HTTP200 canonical ok 0 negazioni. Link in ingresso da Mesmerismus (1582) e fascinazione (11274), backup pre_linkmag_*. Cluster ora: 5 pagine interconnesse
• 14/08 pomeriggio: (a) incipit magnetismo positivizzato (formula Marco, backup pre_incipit)
• (b) pagina INTERVISTA pubblicata post 11291 /blog/intervista-magnetismo-personale/ 15 Q&A parole Marco, link incrociati
• (c) sistema DUE MOTORI (due_motori.py su VM /tmp/pillars): M1 GLM sceglie keyword, M2 giudica semantica sequenza (fallback glm su 429 kimi), applicazione meccanica con GATE sha256 testo-identico. 11285: 78 grassetti+17 corsivi. 11274: 94 grassetti+23 corsivi. Entrambi PUBBLICATI con backup pre_bold_*. Secondo messaggio verificato leggibile. Pagine confermate NUOVE al 100% (slug check pre-create), vecchie intatte: zero perdita SEO
• 14/08 sera: regola domande retoriche v2 (rule_1786726404389_f26u8e + principio 19: UNA per articolo, 70% apertura, mai in FAQ ne accanto a domande vere)
• Q2 rimossa da 11285
• CATENA completata su 197/3576/1582+111sync: pacchetto GLM (Meheust, polivagale, segreti Virgilio, mistero Ficino, domanda retorica, link cluster) + due motori (197: 56 bold/6 em
• 3576: 94/82
• 1582: 19 bold, M2 ha potato 37 kw per ripetizioni marchio). Tutti con sanity+gate sha256+backup pre_pacchetto_*/pre_bold_*. Cluster completo: 7 pagine interconnesse tutte con doppio livello lettura
• 14/08 sera: test traduzione full-AI RIUSCITO: /blog/personal-magnetism/ (post 11312, giudice madrelingua 8/10, gate strutturali ok, interlink IT-EN). Pipeline traduci.py su VM /tmp/pillars: GLM traduce con struttura HTML bloccata -> gate deterministici (tag/URL/marchio/lunghezza/vietati per lingua) -> giudice madrelingua voto>=8 -> publish + interlink. Patch multilingua (VIET_L, note pt/fr). BATCH catena_trad.py LANCIATO: 17 job (11285 pt/fr
• 11274 en/pt/fr
• 11304 en/pt/fr
• 11291 en/pt/fr
• 197 en/pt/fr
• 1582 en/pt/fr), log /tmp/pillars/catena_trad.log, idempotente (skip slug esistenti). Strategia: pagine native per lingua, no plugin, hreflang eventuale dopo con Polylang. Misuratore settimanale gia' multilingua (baseline t0 14/08 in BQ: fascinazione b2 riferimenti 10/10!)
• 15/08: intervista Marco P5 completata (GDoc definitiva 1_jgtIpf6xIdLi-qX36eJPBgCn-P5pBOe0ohuFtOYeQY) -> pillar https://www.neurolinguistic.com/blog/ipnosi-istantanea/ generato con DEEPSEEK (glm in guard budget opencode), 5 citazioni verificate (Donato in persona, Morety, Belfiore, Caroli, Papus), aneddoto Virgilio/guardia del corpo (argomento anti-suggestione), Meheust corpus contraddittori + punto Paret ricerca universitaria, video zfIqe, domanda retorica apertura, 3 blockquote con trad, fix meccanici (2 domande-ponte rimosse). Link in ingresso da 11274, 197, 2329(corso storico). Due motori: 72 bold + 24 corsivi, gate ok (fallback deepseek aggiunto anche a due_motori). Collaudo HTTP200 canonical ok
• 15/08 pomeriggio: (a) 11336 bonificato: 22 paragrafi riscritti positivi (deepseek per paragrafo, gate link), 0 palco/spettacolo, residue solo citazioni Marco e termini tecnici, backup pre_neg_*
• (b) PRESENZA 11348 https://www.neurolinguistic.com/blog/presenza/ pubblicata (intervista GDoc definitiva 1yGx1C5..., non-trance, De Michelis tempo rallentato, 3 bq Olivier/Rosen, mindfulness rispettosa, 99 bold due motori)
• (c) CNV MAGNETICA 11355 https://www.neurolinguistic.com/blog/comunicazione-non-verbale-magnetica/ pubblicata (intervista GDoc 1bRh8..., 93 percento Mehrabian precisato, cluster/gestalt, domanda dietro la domanda, sincronizzazione dalla relazione, Puysegur, bonifica preventiva 10 paragrafi, due motori lanciato dm_cnv.log). Cluster IT: 9 pagine interconnesse. Regola operativa: mai palco/spettacolo, zero negazioni anche nominali (whitelist: termini tecnici e citazioni)
• 15/08 sera: (a) regola v3 DUE domande retoriche (rule_1786806645966_yk8kmj + principio 19 v3)
• seconda domanda inserita su 11274(apertura) 11285 11304 11336 11348 11355 3576 1582+111sync (197 SKIP adiacenza corretta
• 11285 positivizzata da Non-vi-e a Vi-e)
• (b) titoli corretti 'i suoi segreti svelati' su 6 pillar + anchor in 11 pagine
• (c) ALCHIMIA INTERIORE pubblicata 11385 https://www.neurolinguistic.com/blog/alchimia-interiore/ (intervista GDoc 1ry0CLa..., neidan, Egizi-Paracelso-Van Helmont, fasi Opera con citazione Grande Opera, corpo materia prima, segreto respirazione/parasimpatico, bonifica preventiva 14 paragrafi 0 negazioni, 3 bq, 2 domande, FAQ salute, link da presenza/magnetismo/mesmerismus). Cluster IT: 10 pagine
• 15/08 sera: (a) BONIFICA cluster completata (negazioni via da 9 pagine, residue solo legittime)
• (b) batch trad 29 job in corso
• (c) Marco ha risposto a P8 PASSI MAGNETICI (stato parasimpatico, degagement, ricerca passi-vs-parole misurabilita'), P9 SONNAMBULISMO (plesso solare, argomento animali vs suggestionabilita', ipnosi=recovery mode, sviluppo del sonnambulo ottocentesco), P10 SILENZIO (tre stanze/sala dei miracoli [nome maestro ASR da confermare: Raccanelli?], territorio-altro-che-mappa, DMN, area di Broca, dimensione oltre le AI): estrazioni citazioni in coda (cits_passi/sonnambulismo/silenzio)
• GENERAZIONE 3 PILLAR AL PROSSIMO TURNO
• (d) MISURA INTERMEDIA 15/08: fascinazione riferimenti 4/4 con MARCOPARET.COM CITATO IN TUTTE le risposte (it/en, def/mercato) + wiki + mesmerism.info
• magnetismo 0/4 (pagina di ieri, curva da zero: competitor citati = ananda/mindvalley/charismaschool). INSIGHT: marcoparet.com ha gia' autorita' AI -> pagine li' = alta priorita' (TranslatePress 17 lingue moltiplica)

Provato ed escluso

• ipotesi PT-forte smentita dai dati

Prossimo passo

• generare P8/P9/P10 quando citazioni pronte
• strategia pagine marcoparet.com (entity+bio+temi brevi che linkano cluster)
• trascrizioni definitive GDoc
• nomi ASR da confermare con Marco: maestro Bacicci (passi), Raccanelli (tre stanze)

video-proxy-pipeline

Aggiornato 2026-08-16 13:34 UTC — dominio: video / infrastruttura

Obiettivo

Fase 1: proxy 1080p dei 40TB con upload su Storage Box + Yandex; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; futura estrazione WeVideo

Vincoli in vigore

• i 40TB non si muovono mai, solo proxy
• identita clip = label|relpath|size + serial disco, mai lettera
• manifest e stato vivono sul disco
• agente pubblico su wiki: NO credenziali embedded
• niente Storage Box finche Yandex regge

Fatto (con prova)

• Agente Windows autoaggiornante v2.9 (C:/isicnv, Python embeddable+ffmpeg, icona desktop+menu Start) su https://wiki.marcoparet.com/agent/agent.py : rileva dischi da solo, QSV full-GPU 1080p 2Mbps con fallback, anti doppia istanza (bug 47 righe/24 clip risolto), progresso live e stime, catasto dischi in BQ disk_inventory, upload WebDAV Yandex con backlog e retry (creds bootstrap k_9vq2m8xk4t.json, copia in gs tokens-yandex-webdav.json). Yandex verificato: 3TB totali, 1.81 usati, 1.20 liberi, cartella isicnv_proxy creata. Tabelle BQ: video_proxy_tracking con disk_serial, disk_label_map, trascrizioni_index 9860 righe, disk_inventory. Dashboard https://wiki.marcoparet.com/agent/status.html cron 10min con dedup. Dischi: Maxtor 2019-09 2020-03 (2943 video, label=nome canonico) e INTENSO in corso 15/08. Mirror ffmpeg su wiki per problema TLS del PC.
• v2.10 online: fix sdur (assert obbligatori sulle patch) + estensioni .mod/.tod/.3gp/.webm/.flv (431 MOD su INTENSO trovati dal catasto). Catasto INTENSO 54419 file validato. TROVATA pipeline trascrizione VIVA: /home/claudeuser/trascrivi_run.py (fonte rclone gdrive:Audio da Corsi dal vivo per nome disco, Groq whisper-large-v3, chiavi in isicnv/keys/groq_keys.json, resume automatico, flock). Intenso ha solo 164 trascrizioni perche i suoi mp3 (_AUDIO_ESTRATTI, 1501 file 11.6GB) non sono mai saliti tutti su Drive. Export chat Claude 853MB in Drive folder 1TpajgASPSO non serve piu.
• Agente v3.0 PUBBLICATO su https://wiki.marcoparet.com/agent/agent.py (sha256 1ddb5c7d..., backup v2.10 in agent_v2.10_backup.py): per ogni proxy estrae audio mp3 16kHz mono 48k (fallback aac m4a) + miniature cambi scena (soglia 0.35, 360p, max 200, timestamp nel filename sNNNNN_tSEC.jpg + scenes.json
• video statici 1 copertina a meta durata)
• upload Yandex isicnv_audio/<label>/<rel>.mp3 e isicnv_scenes/<label>/<relbase>/
• backlog automatico su clip done senza media via media.csv
• BQ status audio/scenes/audio_up/scene_up. Testato con 3 livelli assert. ATTIVA al prossimo riavvio agente. INTENSO verificato in lavorazione v2.10 (3 done ts 09:05 UTC 15/08)
• trascrivi_yandex.py DEPLOYATO su VM (/home/claudeuser/trascrivi_yandex.py): fonte yandex:isicnv_audio (mp3+m4a), stesso albero output trascrizioni_isicnv/<label>/, meta con disk_label e yandex_path, flock dedicato, rotazione 13 chiavi Groq, ricompressione >24MB. Smoke test ok (0 audio: v3 non ancora riavviata). Cron 15 */6 * * * con log logs/trascrivi_yandex.log. Remote rclone yandex webdav configurato su VM
• creds copiate in gs://isicnv-command-center-routes/tokens/tokens-yandex-webdav.json. Tabella BQ isicnv_workflows.video_scenes CREATA (clip_id, scene_n, t_sec, thumb_yandex_path, vision_labels, vision_desc, is_demo, vision_model). Mirror wiki cantiere di nuovo funzionante (saveRevision risolto)
• v3.1 PUBBLICATA (sha 5bf72d28...): miniature ora estratte dall'ORIGINALE sul disco collegato a 720p (fallback proxy se assente), encoder BQ dichiara la fonte (scene0.35-orig/proxy). Testato: scena a t=3.0 dall'originale mentre il proxy era statico
• fallback verificato. trascrivi_yandex v2: salva SEGMENTI TEMPORIZZATI whisper (start/end/testo) nel .json meta - base per allineamento scena-parlato e 'momento reazione' - e inserisce in BQ trascrizioni_index (batch 25, flush finale). Smoke test ok.
• v3.1 VERIFICATA IN PRODUZIONE post-riavvio Marco: BQ mostra 2 audio (a16k-mono) + 2 scenes (scene0.35-orig, dagli ORIGINALI) + 5 done alle 09:31-09:42 UTC
• upload media in coda dietro i proxy (fisiologico). v3.2 PUBBLICATA (sha 31165499...): SISTEMA PUSH - da idle a code vuote, ogni 10 min l'agente controlla wiki: versione nuova -> scarica, compile-check (se rotta resta sulla vecchia), sostituisce e si riavvia da solo con os.execv
• inoltre legge control.json (force_restart_ts) per riavvio remoto senza cambio versione. Testato con 5 assert (update, no-op, protezione codice rotto, throttle, restart remoto). Da v3.2 in poi NESSUN riavvio manuale servira' piu': pubblicare = deployare. Riavvio remoto: scrivere force_restart_ts=epoch futuro in /var/www/wiki/agent/control.json su Hetzner
• v3.3 PUBBLICATA (sha d434a9f7): HEARTBEAT ogni 5 min in BQ agent_heartbeat (versione, disco, clip corrente, attivita, code, uptime) + AUTOSTART con Windows (shortcut in shell:startup, si crea da solo al primo avvio). Dashboard status.html AGGIORNATA (backup gen_video_status_backup.py): banner vivo in cima con semaforo ATTIVO<=12min/SILENZIOSO<=40/SPENTO?, versione, clip in corso, code, contatori audio/scene estratti e caricati
• fix VEXT con .mod/.tod/.3gp/.webm/.flv nel catasto. Verificata pubblica. MODELLO OPERATIVO COMPLETO: PC acceso col disco + tutto guidabile da remoto (push deploy, riavvio via control.json) + monitoraggio mobile su https://wiki.marcoparet.com/agent/status.html
• v3.4 PUBBLICATA (sha 70b15e2a): FIX heartbeat (backslash Windows rompevano la SQL: solo 1 battito in 7h - ora sanificati e INSERT provato reale su BQ), FIX timeout upload Yandex (era 300s fisso -> 0 proxy INTENSO caricati per read timeout su file grandi
• ora dinamico 600-3600s in base alla size), errori upload VISIBILI (contatore+ultimo errore nel heartbeat con colonne up_err/last_err via ALTER, riga upload_err in tracking alla prima occorrenza per clip), check aggiornamenti anche AL CONFINE TRA CLIP (senno mai idle su dischi da 450h e il push non scattava mai), GUARDIA disco staccato (stop pulito, clip error ritentate al ricollegamento - verificato: pending esclude solo status done). Dashboard aggiornata con riga rossa errori upload. NOTA: v3.3 in esecuzione si aggiorna solo da idle: lo swap dischi di Marco (chiudi-riapri contestuale) carica v3.4.
• v3.4 CONFERMATA VIVA post-swap (battiti regolari con clip corrente, fix heartbeat funziona). v3.5 PUBBLICATA (sha f4da4f50) - PLUG-AND-PLAY COMPLETO: (1) set ENQ anti-duplicati sulle code (le ri-scansioni ogni 30s duplicavano gli item non ancora caricati), (2) rilascio chiave su file mancante cosi al ricollegamento il backlog riaccoda, (3) skipped &= drives: un disco che dava errore veniva ignorato per sempre fino al riavvio, ora l'estrazione cancella l'errore e il reinserimento riparte pulito. 4 assert passati. E' il PRIMO deploy push reale: v3.4 la carichera al confine della prossima clip.
• v3.6 PUBBLICATA (sha 1aad55e7, supera v3.5 mai installata - l'agente v3.4 in esecuzione su Maxtor salta direttamente a v3.6 al confine clip): (1) LOG REMOTO: ogni riga log() bufferizzata e spedita a BQ isicnv_workflows.agent_log col battito ogni 5 min (sanificata, testata con INSERT reale), visibile a Claude via BQ e sulla dashboard (sezione 'Ultime righe di log')
• (2) FILTRO FILE FANTASMA: scan_videos salta ._* (AppleDouble macOS, causavano ERRORE transcodifica su Maxtor) e file <64KB. Include tutte le migliorie v3.5 (dedup ENQ, rilascio chiavi, skipped auto-dimenticato = plug-and-play). Dashboard rigenerata OK 101.
• PUSH VERIFICATO FUNZIONANTE: agente auto-aggiornato v3.4->v3.6 nella notte senza mani. Avanzamento 16/08: INTENSO 72/1526 (4.7%), Maxtor 119/2944 (4%), ~50 clip/notte. PROBLEMA APERTO: upload Yandex ancora in read-timeout anche con timeout 3600s (289 in coda, solo 4 proxy passati) - non e' questione di timeout ma di banda/WebDAV. v3.7 PUBBLICATA (sha in wiki): coda upload a PRIORITA by-size (audio e thumb passano davanti ai proxy -> trascrizioni e strato semantico fluiscono anche se i proxy arrancano) + METRICHE velocita (MB/s e durata su ogni successo/fallimento nel log remoto, e nell'ultimo errore heartbeat). Assert passati (priorita, dedup, rilascio).
• STORAGE BOX ESISTENTE TROVATA (Marco aveva ragione): u649132.your-storagebox.de, BX11 1TB usata 7GB (backup CC/BQ, cron storagebox_backup.py). NIENTE UPGRADE ORA: 1TB copre mesi (proxy totali stimati 1.6TB a fine 40TB)
• upgrade BX21 con un click quando serve. Setup: chiave dedicata sb_agent_ed25519 generata su VM e autorizzata sulla box (separata dalla chiave backup), cartella isicnv_proxy creata, test scp reale 30MB in 2s (15MB/s). Creds agente su https://wiki.marcoparet.com/agent/k_sb_7hq4x9m2vt.json + GCS tokens/tokens-storagebox-agent.json. v3.8 PUBBLICATA: PROXY -> Storage Box via scp Windows OpenSSH (mkdir -p remoto con cache, quoting spazi testato sui path RUSSIA TORINO, ACL icacls sulla chiave, timeout by-size, fallback Yandex se scp assente), audio+thumb restano su Yandex (trascrittore gia' li'). encoder BQ scp-sb vs webdav.
• Chiarito tema snapshot/backup-del-backup: snapshot Hetzner sono copy-on-write - i proxy write-once costano ~0 byte negli snapshot
• costo solo su modifiche/cancellazioni future
• i proxy sono comunque rigenerabili dagli originali (dati derivati, non preziosi)
• lo script VM spinge backup VERSO la box, non fa immagini della box. Dashboard: aggiunta riga 'Storage Box (proxy + backup): usati X su 1TB' con allarme rosso a 78% e nota upgrade BX21 (fix parsing df: shell ristretta box a volte ignora il pipe tail, ora si parsa l'ultima riga non-header). Verificata pubblica: 7.1G/1TB (1%). Agente ancora v3.7 su clip lunga: v3.8 attesa al prossimo confine clip.
• MILESTONE: PRIME TRASCRIZIONI AUTOMATICHE end-to-end. 10 audio su Yandex (priorita v3.7 funziona), trascrivi_yandex manuale: ok=5 skip=5 err=0, lingue auto (IT/EN), 267 e 364 segmenti temporizzati, BQ trascrizioni_index +5. Il ciclo disco->proxy->audio->Yandex->Groq->testo+tempi->BQ e' VIVO. 24 miniature su Yandex. v3.8 in attesa del confine clip (clip 12/1437 gigante in corso, v3.7 batte regolare). Calcolo fattibilita consegnato: proxy 0.9GB/h video, scenari 1.7-4.5TB per 40TB, 3.5-10 mesi su 1 PC, box 1TB regge ~2 mesi poi BX21
• Marco valuta secondo PC.
• v3.8 ATTIVA (terzo push riuscito, proxy->StorageBox da ora). v3.9 PUBBLICATA (sha 26e7b459): ANTI-STANDBY Windows via SetThreadExecutionState - il PC non va a riposo finche' l'agente e' aperto (schermo puo' spegnersi), elimina il rischio principale del PC-sempre-acceso. Strategia Marco confermata: priorita' INTENSO (~10TB recenti). Stima INTENSO: ~460h video 4K -> proxy ~410GB (sta nel 1TB attuale senza upgrade), audio ~10GB, ~27 giorni di lavoro a ritmo attuale.
• CENSIMENTO DRIVEUPLOADER COMPLETATO (richiesta Marco): 45 cartelle radice, 190 cartelle totali, 2668 video = 3.19TB su Drive isicnv, con md5 e path, in BQ isicnv_workflows.drive_video_census (script VM census_driveuploader.py, token root bucket NON tokens/). Incrocio col catasto: solo 39 match sui 2 dischi finora catastati (Maxtor) -> il grosso dei video Drive viene da dischi non ancora analizzati, come previsto da Marco. Vista permanente v_drive_vs_dischi: ogni NUOVO disco catastato si confronta da solo (match nome+size, md5 disponibile per verifiche forti). USO: prima di caricare/processare un disco si vede subito cosa esiste gia in cloud
• i 3.19TB su Drive sono anche processabili DALLA VM senza disco fisico (opzione futura per proxy/trascrizioni di materiale non piu su disco).

Provato ed escluso

• Storage Box Hetzner rimandato: nessun token API esiste e Marco preferisce Yandex gia pagato
• GCS e volumi cloud bocciati per costo
• la lentezza 1.1x della v2.4 era DOPPIA ISTANZA, non hardware

Prossimo passo

• 1) primi MB/s StorageBox (v3.8 attiva) e svuotamento coda 2) cron trascrizioni autonomo 3) vision -> video_scenes 4) opzione: processare i video Drive direttamente da VM (niente disco fisico) 5) ogni nuovo disco: query v_drive_vs_dischi per skip/conferme

harness-standard

Aggiornato 2026-08-15 08:25 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
• COLLAUDO DETERMINISTICO costruito su proposta di Marco (catena di agenti con controllore): scripts/collaudo.py. Sta fra chi produce e chi riceve: niente passa allo stadio successivo se non lo supera
• SETTE CONTROLLI, tutti deterministici: pagina risponde 200, contenuto sopra soglia di parole, nessun segnaposto lorem ipsum o TODO o errore PHP visibile, blocchi strutturali attesi presenti, frasi che devono esserci, termini vietati assenti (controllo mentale, potere sugli altri, manipolazione), link controllati uno per uno con HEAD, rendering reale via shot.py con peso e errori console
• PROVATO SU PAGINE VERE: lastampa-2002 PASSA (832 parole, 2 link sani, 157 KB). autostima-ipnosi-shock PASSA. cairn/ RESPINTO per 2 link rotti verso fonts.googleapis e fonts.gstatic. Pagina inesistente RESPINTA correttamente
• DIFFERENZA DALLA PROPOSTA DI MARCO: il controllore NON e un secondo LLM. Misura nostra: il giudice LLM dava 5, 2, 4 sullo stesso documento. Un controllore che oscilla di 3 punti su 6 inventa difetti e ne manca di veri
• CONTEGGIO TOKEN gia disponibile: il gateway aigw logga client, token in e out e costo per chiamata. Base pronta per il budget per task chiesto da Marco
• CATENA AUTONOMA costruita: piano.py --esegui. Esegue in sequenza tutti i punti aperti del piano, marca FATTO o FALLITO, e SI FERMA al primo fallimento avvisando su Telegram. La catena vive sulla VM, non dentro la chat
• PROVA A TRE STADI: produrre, collaudare, pubblicare. Il collaudo sulla pagina CAIRN ha RESPINTO per i 2 link rotti verso fonts.googleapis e fonts.gstatic, e il punto 3 NON e stato eseguito. Verificato: /tmp/catena_out.txt contiene solo il prodotto del punto 1
• DIAGNOSI della chat Marketing che chiedeva scrivimi vai: due cause. La prima e strutturale e non e colpa sua, una chat non puo risvegliarsi da sola, il turno finisce quando emette il messaggio. La seconda si: non aveva passato il lavoro alla macchina che PUO continuare. Verificato che quella chat non ha lasciato nulla in esecuzione, ne job ne battito ne servizio: estrazione citazioni in esecuzione viveva solo nella conversazione
• Il pezzo mancante era proprio questo: ora chi crea un piano lo lancia con job.py --run piano.py --id X --esegui e la catena prosegue senza Marco
• FALSO DIFETTO DEL COLLAUDO TROVATO E CORRETTO: i due link fonts.googleapis e fonts.gstatic sulla pagina CAIRN NON erano rotti, sono rel=preconnect, suggerimenti di connessione al browser e non risorse da scaricare. Il collaudo li contava come link. Ora esclude preconnect, dns-prefetch, preload, prefetch, alternate. La pagina CAIRN ora PASSA: 669 parole, 7 link controllati, 0 rotti, 246 KB
• VERIFICA GENERALE DEL SISTEMA: 4 cron attivi (finance_daily 06:45, riapplica_regole 07:10, sentinella 03:20, guardiano_battito ogni 2 min), 14 strumenti sulla VM
• LEDGER: da 1.743.096 euro non classificati a 84.298 su 1.320 movimenti. Il cron riapplica_regole HA TENUTO stanotte, il lavoro non e stato piu azzerato dal sync
• MASTER v7.10 con APPENDICE 0 - LA RICETTA UNICA. Nasce dal caso ChatGPT che diceva parto adesso e poi cercava job.py su Google Drive facendo un passo solo
• DUE CAUSE DIAGNOSTICATE: 1) job.py e piano.py NON sono file da cercare su Drive, stanno sulla VM e si invocano via POST /vm/exec-direct. Ora scritto in maiuscolo nellappendice. 2) Un modello fa UNA chiamata per turno e poi si ferma, quindi la ricetta deve creare piano, battito e catena in una chiamata sola
• RICETTA PROVATA DAVVERO: una sola chiamata ha creato il piano di 3 punti, registrato il battito e lanciato la catena. Risultato 3/3 completati, collaudo incluso, senza altri interventi
• Regola aggiunta: se dopo la tua chiamata resta ancora qualcosa da avviare, non hai avviato, hai cominciato. Mai dire parto adesso senza aver fatto quella chiamata
• Pubblicata e verificata su Drive, txt id 1t6VnTHN5fQXlcJhkqWY6SXe7vmnglLzG
• DIAGNOSI chat ChatGPT brand dr. Paret che avanzava di un passo solo: stava cercando job.py su GOOGLE DRIVE. Gli strumenti stanno sulla VM in /home/claudeuser/scripts/. Il Master non lo diceva, e non menzionava piano.py --esegui
• MASTER v7.11 pubblicata con STEP 5-BIS Lavori lunghi si avviano tutti i blocchi non uno: piano --crea, poi job.py --run piano --esegui, battito, collaudo fra gli stadi, e i comandi per controllare lavanzamento senza restare in chat. Vietato chiudere con scrivimi vai
• APPENDICE A estesa per modelli non-Claude con le due chiamate HTTP esatte e la riga esplicita: gli strumenti sono sulla VM, NON su Google Drive
• Verificato su canonico e su txt: STEP 5-BIS presente in entrambi, 24.670 byte, id 1WJhgFa_Q10au3ZdmbYnAYAUCIdrOaEfj
• ERRORE MIO: al primo tentativo lo script di modifica cercava il file v7_9 gia rinominato, e falliva
• ho pubblicato la v7.10 SENZA la modifica. Se ne e accorto solo il controllo di contenuto (STEP 5-BIS: False). Rifatto sul file giusto
• VERIFICATA la chat Marketing che chiedeva scrivimi vai: il lavoro dichiarato in esecuzione NON era in esecuzione. /opt/oracle_cita/cita_wiki.py esisteva ma nessun output, nessun job, e il servizio tunnel-rerank era inactive (il punto 3 del suo stesso controllo sarebbe fallito)
• CAUSA della richiesta di vai: quella chat e partita PRIMA della v7.11. Una chat legge il Master una volta sola allinizio
• pubblicare una versione nuova su Drive non cambia nulla per chi sta gia lavorando, il contesto e congelato
• LANCIATA IO la catena vera: piano citazioni-pilastro 4 punti, eseguita interamente da sola. Risultato: 1 citazione VALIDA, 7 SCARTATE dal gate verbatim contro il corpus BM25. Output 4.040 byte su /home/claudeuser/out_citazioni.json
• Il gate ha funzionato: 7 citazioni su 8 non erano verificabili parola per parola nel corpus e sono state respinte. Senza quel cancello sarebbero finite sul pilastro
• QUINTO PEZZO COSTRUITO su schema di Marco: scripts/riparatore.py, cron ogni 5 minuti. Chiude il ciclo progetto-deliverable-agenti-log-ripresa-FINITO
• DUE LIVELLI, e la distinzione e il cuore del progetto. GUASTI NOTI: riparazione deterministica da manuale (servizio spento, cost guard scattato, disco pieno, fetch failed, cartella di root) — esegue il rimedio e rimette il punto in coda, nessun modello coinvolto. GUASTI SCONOSCIUTI o rimedio noto fallito: un modello DIAGNOSTICA e PROPONE un comando, che viene scritto nel piano e mandato su Telegram ma NON eseguito
• STATO FINITO: quando tutti i punti sono FATTO il piano viene marcato finito e parte lavviso. Gia scattato su prova_piano e ricetta_prova
• PROVA SUL CASO REALE: piano che verifica tunnel-rerank. Punto fallito, riparatore riconosce servizio spento, tenta systemctl restart, SCOPRE che tunnel-rerank.service NON ESISTE (la chat Marketing controllava un servizio mai creato), poi propone: diagnosi servizio non installato, comando systemctl enable --now. Proposta scritta nel piano e inviata, NON eseguita
• 5 automazioni in cron: guardiano ogni 2 min, riparatore ogni 5 min, sentinella 03:20, finance_sync 06:45, riapplica_regole 07:10
• CONSENSO A DUE costruito su richiesta di Marco: scripts/consenso.py. Autorizza o nega lesecuzione automatica di una riparazione proposta
• ORDINE DEI CONTROLLI, e lordine e la parte importante: 1) VETO DETERMINISTICO a costo zero su distruttivo (rm -rf, DROP, TRUNCATE, git push --force, chmod 777, reboot, iptables, crontab -r, gcloud --set-env-vars) e su verso terzi (mailwizz, campagne, stripe, paypal, pubblicazioni). Nessun consenso puo scavalcarlo. 2) REVERSIBILITA: senza comando di annullamento si va da Marco. 3) CONSENSO A DUE modelli indipendenti, entrambi devono dire SI. 4) COSTO pochi centesimi
• PROVATO SU 4 CASI: distruttivo respinto dal veto, invio a liste respinto dal veto, comando senza annullamento respinto dalla reversibilita, caso reale del servizio respinto dal consenso
• TRE DIFETTI MIEI CORRETTI durante le prove: un revisore che va in errore veniva contato come voto contrario (ora si distingue non ha risposto da contrario, e in dubbio non si esegue)
• i modelli rispondono in prosa e non in JSON, il parser cercava solo le graffe
• qwen e glm non danno JSON affidabile, sostituito con claude-haiku
• OSSERVAZIONE IMPORTANTE: sui 4 casi provati il sistema non ha MAI autorizzato in automatico. Sul caso innocuo (svuotare /tmp oltre 2 giorni) deepseek dice si e haiku dice no perche potrebbero esserci file in uso. La prudenza e asimmetrica per costruzione e va bene, ma va misurato quante riparazioni vere passano davvero
• MANUALE DELLE RIPARAZIONI PRE-APPROVATE costruito su richiesta di Marco, derivato dai guasti REALI: 51 learnings del CC, 22 sintomi distinti estratti, piu i guasti trovati questa settimana. File in gs state/manuale_riparazioni.json: 16 riparazioni di cui 11 PRE-APPROVATE
• PRE-APPROVATE (si eseguono senza Marco): VM in fetch failed (reset piu 90s), cold start Cloud Run, disco pieno CON BACKUP SU GCS PRIMA di cancellare come chiesto da Marco, cost guard scattato solo se le soglie sono gia rientrate, servizio systemd fermo, start-limit-hit, pacchetto python mancante da PyPI solo con almeno 3 GB liberi, rate limit 429, eseguibile corrotto da ripristinare da backup, permessi cartella root, /vm/task falso ok
• NON PRE-APPROVATE (passano dal consenso o da Marco): installare un servizio mai esistito, token invalid_grant, gcloud --set-env-vars, parametri sbagliati di query, mail non arrivata
• OGNI RIPARAZIONE HA: sintomo regex, diagnosi, verifica_prima (condizione da soddisfare prima di agire), comando, comando di annullamento
• Il manuale sta in un FILE su GCS, non nel codice: si aggiorna senza toccare il riparatore
• PROVA: piano con modulo python mancante, il riparatore ha riconosciuto pacchetto_python_mancante, verificato lo spazio, tentato linstallazione da PyPI
• DIFETTO TROVATO E CORRETTO: i comandi con pipe mascheravano il codice di uscita (pip falliva ma risultava rc 0). Aggiunto set -o pipefail
• LA v7.11 HA FUNZIONATO: la chat ChatGPT ha letto il Master aggiornato, riconosciuto che la sua automazione precedente era basata sulla v7.9, rifiutato di prendere un DONE come prova, e dichiarato PARZIALE invece di fingere. Comportamento corretto
• MA ha riportato DNS del Command Center non risolvibile. VERIFICATO: il CC risponde 200, DNS 34.143.75.2. Il guasto era dal suo lato
• CAUSA NEL MIO TESTO: lAppendice A diceva POST /vm/exec-direct e ChatGPT lo interpretava come chiamata HTTP dal proprio sandbox di codice, che NON HA RETE. La sua unica uscita e il connettore MCP del Command Center
• SECONDA CAUSA misurata adesso: il primo colpo sul CC dopo inattivita impiega 26 secondi (cold start Cloud Run). Con un timeout corto sembra morto
• MASTER v7.12 pubblicata: Appendice A ora apre con DA DOVE ESCI VERSO IL COMMAND CENTER. ChatGPT usa cc_vm_exec e gli altri strumenti del connettore, non curl. Se non li vede, il connettore non e attivo e lo deve dire invece di provare HTTP. Aggiunto lavviso sul cold start con timeout minimo 60 secondi e una riprova prima di concludere. Verificato su canonico e txt, id 15cgM5o5RgKV87XHkTmvtOaZp4LGodSxr
• GUASTO VERO TROVATO dalle notifiche Telegram: DISCO VM AL 100 PER CENTO, zero byte liberi. Causa: /home/claudeuser/backup_staging/bucket_mirror, 4,8 GB creati oggi alle 18:32 da unaltra chat che ha copiato in locale il bucket GCS
• EFFETTO SUBDOLO: tutte le scritture fallivano IN SILENZIO producendo file vuoti. Tre miei tentativi di patch sono arrivati come file da 0 byte senza alcun errore. Il sintomo sembrava un problema di trasferimento, era il disco
• VERIFICATO che il mirror era identico al bucket (stessi nomi di primo livello) prima di rimuoverlo: loriginale resta su GCS. Disco da 100 a 98 per cento, 1,1 GB liberi
• DIFETTO MIO CORRETTO: il riparatore diceva di applicare le proposte con piano.py --sostituisci N, un comando CHE NON ESISTEVA. Sei proposte inviate su Telegram, tutte ineseguibili. Implementati --sostituisci N --comando e --applica-proposta N, provato su una proposta vera
• ANTI-RIPETIZIONE: il riparatore non rimanda la stessa proposta due volte
• AVVISO CLONI: se un piano ha 3 o piu versioni avvisa. Caso reale: paret_pillars_draft v1 v2 v3 v4, una chat clonava il piano invece di correggere il punto fallito
• MANUALE aggiornato: la riparazione disco_pieno ora rimuove anche le copie locali del bucket
• SKILLS STANDARD: installati in ~/.claude/skills 4 skill google/skills (bigquery-basics, cloud-run-basics, gcs-basics, gcloud) dopo audit: solo Markdown, zero script eseguibili, guardie esplicite su delete/IAM/billing. Commit pinnato 9bb184823bd157d9a88d999e2c47ad6dd21fc3fb in AUDIT_PIN.txt
• Creati 3 skill ISI-CNV formato SKILL.md (isicnv-spedizioni, isicnv-infra-vm, isicnv-bigquery): regole dure inline + caricamento canonico via /memory2/search, il canonico vince sempre
• DISCO VM era al 100 per cento: liberati 3,6GB (cache pip/hf, tmp>2gg, apt clean, journal vacuum 40M, snap revisioni disabilitate, refresh.retain=2), ora 93 per cento
• GESTORE DELLO SPAZIO costruito: scripts/spazio.py, cron ogni 20 minuti. Censisce tutti i dischi e agisce per soglia invece di aspettare il collasso
• CENSIMENTO al 13/08 ore 19: VM 94 per cento con 4 GB liberi su 49. Translator 81 per cento con 15 GB su 75. Media 30 per cento con 101 GB su 150. Secondary 30 per cento con 26 GB su 38. La VM soffocava mentre media aveva 101 GB liberi
• TRE LIVELLI: a 85 pulizia (tmp oltre 1 giorno, log troncati a 10MB, job chiusi oltre 2 giorni, screenshot oltre 3 giorni, copie locali del bucket)
• a 90 archiviazione delle cartelle FREDDE su gs archivio_vm con manifesto e poi liberazione
• a 95 avviso Telegram
• SICUREZZA: nulla viene cancellato prima di essere su GCS, e ogni archiviazione lascia un manifesto in archivio_vm/_manifesti con il comando per tornare indietro. Se il caricamento fallisce la cartella NON viene toccata
• CARTELLE CALDE protette per nome: scripts, jobs, isicnv, biblioteca, .ssh
• ESEGUITO: pulizia da 94 a 88 per cento, archiviazione in corso, regazzoni gia su GCS
• MANUALE aggiornato: spazio_gestito sostituisce disco_pieno, pre-approvata
• DIFETTO DEL GESTORE SPAZIO TROVATO E CORRETTO. Primo giro: due istanze in corsa (il mio job e il cron delle 19:00 che parte allo stesso minuto), manifesto di regazzoni scritto 3 secondi dopo lavvio quando 1,9 GB non possono essere caricati in 3 secondi. NESSUNA PERDITA di dati, ma nessuno spazio liberato
• CORREZIONI: lucchetto fcntl DENTRO lo script, cosi nemmeno un lancio a mano puo affiancarsi al cron
• e VERIFICA DEL CONTEGGIO FILE su GCS prima di cancellare, invece di fidarsi del codice di uscita di gsutil
• SECONDO DIFETTO: le soglie erano di panico non di obiettivo. A 88 per cento partiva solo la pulizia, larchiviazione da 90: il sistema oscillava sotto 90 senza liberare mai, mentre su GCS cerano gia 3,5 GB di copie duplicate
• CREATO sposta_freddo.py con OBIETTIVO 75 per cento e due destinazioni scelte per uso: GCS per la sola conservazione, media (101 GB liberi) per cio che deve restare LEGGIBILE da disco come la biblioteca dellOracolo
• IN CORSO: OpenMontage gia liberato, disco da 89 a 85 per cento, biblioteca in copia verso media
• SPAZIO RISOLTO. Job sposta completato in 57 minuti, obiettivo 75 per cento raggiunto. Liberate e archiviate su GCS con verifica del conteggio file: OpenMontage 1656 MB 18.333 file, openmontage 537 MB, union 596 MB, neuro_encoding_work 518 MB 23.294 file, chat_archive 431 MB
• BIBLIOTECA SPOSTATA su media:/opt/biblioteca_vm, 379 file da entrambe le parti verificati
• GUASTO CHE AVEVO INTRODOTTO: dopo lo spostamento /home/claudeuser/biblioteca era un collegamento a /mnt/biblioteca_media che NON ESISTEVA. Tutti gli script che leggono la biblioteca avrebbero trovato il vuoto. Risolto: installato sshfs, abilitato user_allow_other in /etc/fuse.conf, montato. Verificato: 287 file visibili e lettura reale di ingest.py funzionante
• MONTAGGIO RESO PERMANENTE: cron ogni 10 minuti che rimonta se il punto di montaggio cade, piu un @reboot con 60 secondi di attesa
• DUE CAUSE TROVATE per il lotto traduzioni fermo senza riprendere. PRIMA: zero piani registrati per le traduzioni. Il guardiano NON e un sorvegliante di processi, riprende solo cio che e registrato come piano con battito. Quel lotto non lo era, quindi non cera nulla da riprendere
• SECONDA E PIU GRAVE: il guardiano era BLOCCATO DAL COST GUARD da oltre un giorno, in silenzio. Il codice faceva break sullintero ciclo, quindi NON riprendeva nulla, nemmeno i lavori che i modelli non li usano. Nel log: cost guard TRIPPED non riparto, ripetuto ogni 2 minuti dal 13 agosto
• Il guard stavolta ha ragione: credito OpenRouter residuo 2.62 USD sotto la soglia di 5.00, settimana 38.06
• CORREZIONE 1 - GUARD SELETTIVO: il cost guard ora blocca SOLO le riprese il cui comando o stato menziona modelli (openrouter, aigw, deepseek, glm, kimi, qwen, grok, claude, oracolo, traduzioni). Tutto il resto riprende normalmente. E avvisa Marco UNA VOLTA al giorno invece di scrivere nel log ogni 2 minuti
• CORREZIONE 2 - PARCHEGGIO: i lavori che esauriscono le ripartenze vengono chiusi con avviso Telegram invece di riempire il log per sempre. Gia scattato su migrazione-aigw
• TROVATO: paret_pillars_draft esiste in SETTE versioni v1..v7, una chat continua a clonare il piano invece di correggere il punto fallito
• REGISTRO DEI PROCESSI costruito su proposta di Marco, ed e migliore di quanto avevo fatto io: tutti i miei meccanismi dipendono dal fatto che una chat SCELGA di registrarsi, il suo no. Chi non logga non usa i modelli: e applicazione, non disciplina
• scripts/processo.py: ogni iniziativa ha numero, nome, deliverable finale, elenco di fasi, casella corrente, stato, ultimo log, token e costo. Comandi: --apri, --n N --log, --avanza, --blocca, --chiudi, --tabella, --fermi
• APPLICAZIONE AL GATEWAY: aigw.py legge /opt/aigw/processi.json e controlla lheader X-Processo. Una chiamata senza processo, o con un processo fermo da oltre 20 minuti, viene registrata come 428. Modo SOFT: per ora registra e lascia passare, cosi nulla si rompe. Passando PROC_MODO a DURO rifiuta
• Backup di aigw.py in aigw.py.bak_processo
• SINCRONIZZAZIONE: la VM spinge il registro sul gateway ogni minuto (spingi_processi.sh in cron). Il download diretto da GCS dava 403, il bucket non e pubblico
• Aperto il processo 1: traduzioni multilingua, deliverable 17 pagine tradotte e collaudate, 5 fasi
• Gateway riavviato e attivo, registro presente 563 byte
• CAUSA DEI 503 TROVATA E RISOLTA: Cloud Run era configurato con minScale=0, quindi spegneva il servizio quando inattivo e il primo colpo doveva riaccenderlo. Non era un guasto, era la configurazione. Applicato --min-instances=1 --no-cpu-throttling. MISURATO PRIMA: 26 secondi e 503 intermittenti. DOPO: 0,17 secondi, 5 chiamate su 5 a 200
• AVVISO GLOBALE implementato su proposta di Marco: processo.py --avviso-globale scrive un messaggio che compare come campo DA_LEGGERE in OGNI riga attiva della tabella, finche il processo non dichiara --letto. Gia usato per annunciare la v7.12 del Master
• COSTO PER PROCESSO: processo.py --n N --costo X --token Y accumula sulla riga, cosi la tabella diventa anche il conto di quanto e costato ogni deliverable
• GUARDIANO COLLEGATO AL REGISTRO: ogni 2 minuti legge processo.py --fermi e segnala su Telegram i processi che non loggano da oltre 20 minuti, anche quelli senza battito. Gia scattato sul processo 1
• NOTA per Marco: il 503 riguardava Cloud Run, NON la VM. Ampliare la VM non avrebbe risolto nulla. Un secondo accesso MCP nemmeno: il servizio era vivo, solo addormentato
• ESENZIONI aggiunte al gateway su indicazione di Marco: chi sorveglia non puo dipendere dal registro che sorveglia, si bloccherebbe da solo quando il registro ha un problema. Esenti per natura: sovrintendente, guardiano, riparatore, sentinella, spazio, listino, eval, diagnosi, cc. La lista si estende dal registro stesso, campo esenti, senza toccare il codice. Backup aigw.py.bak_esenti
• CRON DI ANALISI installato alle 08:15: analisi_processi.py legge calls.jsonl, conta quante chiamate in modo DURO sarebbero state rifiutate, dice CHI le fa e perche, e propone una decisione. Non cambia nulla da solo
• DIFETTO MIO TROVATO SUBITO: la prima esecuzione diceva 210 chiamate, 0 rifiutate, si puo passare a DURO. Falsa via libera: contava chiamate PRECEDENTI allinstallazione del controllo, quando il controllo non esisteva e quindi non poteva rifiutare nulla. Corretto: ora parte dal momento di attivazione, registrato in .registro_processi_attivo, e se le ore di osservazione sono meno di 12 dice ASPETTARE invece di proporre
• Secondo difetto corretto: confronto fra date con e senza fuso orario
• ESENZIONI RESE PROGRESSIVE su indicazione di Marco. Unesenzione data una volta e mai piu guardata diventa un buco: ora e concedibile, MOTIVATA e con SCADENZA
• processo.py --esenta NOME --perche \"...\" --giorni 30 (il motivo e obbligatorio, senza non si potrebbe rivedere), --revoca NOME, --esenzioni per lelenco con giorni alla revisione e marcatore DA_RIVEDERE
• DUE LIVELLI: esenti per natura nel codice (sovrintendente, guardiano, riparatore, sentinella, spazio, listino, eval, diagnosi, cc) che non scadono perche sono i sorveglianti
• ed esenzioni CONCESSE che scadono e vanno riconfermate
• PRIMA CONCESSA: oracolo-agent, motivo servizio di consultazione sempre attivo non e un progetto con deliverable, revisione fra 30 giorni
• LANALISI GIORNALIERA ORA PROPONE I CANDIDATI: chi viene rifiutato in oltre l80 per cento delle sue chiamate e con almeno 5 rifiuti finisce nellelenco candidati, con il comando pronto per esentarlo. E segnala le esenzioni SCADUTE da riconfermare o revocare
• Il gateway legge le esenzioni concesse dal registro, senza modifiche al codice

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
• Secondo agente LLM come controllore di qualita: varianza inaccettabile, misurata. LLM solo dove il criterio e davvero qualitativo, mai per verificare fatti controllabili
• Fidarsi che una pagina sia a posto perche risponde 200: cairn risponde 200 e ha due link rotti
• Chiedere a Marco di scrivere vai per far proseguire: e usarlo come schedulatore. La chat crea il piano e lo lancia, poi puo anche morire
• Far proseguire la catena dopo un collaudo respinto: si ferma e avvisa, con lelenco preciso dei difetti
• Riparare i link CAIRN: non erano rotti. Prima di riparare, verificare che il difetto esista. Un controllore che segnala falsi difetti e il male che volevamo evitare, e il mio lo faceva
• Spiegare a parole a un modello esterno come avviare un lavoro lungo: serve un blocco copiabile con una chiamata sola, non una procedura a passi
• Fidarsi dello status 200 delle upload: la verifica deve leggere il CONTENUTO. E la terza volta che questo controllo salva una pubblicazione sbagliata
• Chiedere a Marco di scrivere vai: il lavoro andava lanciato come catena
• Il mio primo tentativo di catena e fallito al punto 1 per virgolette annidate dentro ssh: risolto mettendo i comandi in cita_step.sh invece che inline
• Un agente che legge il log e decide ed esegue comandi da solo: e la strada al danno non sorvegliato. Esegue solo rimedi da manuale gia scritti
• per il resto propone e decide Marco
• Insistere con un rimedio noto che fallisce: ora al primo fallimento passa alla proposta
• Lasciare che due modelli daccordo scavalchino il veto deterministico: possono sbagliare insieme, il nostro giudice LLM oscillava di 3 punti su 6
• Contare un errore tecnico di un revisore come voto contrario: e sicuro ma e una bugia sulletichetta
• Inventare la lista dei guasti: e stata estratta dai 51 learnings e dai sintomi realmente registrati
• Mettere il manuale nel codice: sta su GCS cosi si estende senza modificare il riparatore
• Dare per buono un DNS non risolvibile riferito da un modello: il CC risponde 200 da qui. Prima di credere a un guasto, verificarlo dal proprio lato
• Cancellare backup_staging senza verificare: prima confrontati i nomi con GCS
• Continuare a patchare un file quando le scritture falliscono: il problema era il disco, non il codice
• NVIDIA e MicrosoftDocs skills: fuori stack
• addyosmani/mattpocock: quality gates gia coperti da V/B/C e giudice/verifica
• Aspettare che il disco arrivi al 100 per cento: le scritture falliscono in silenzio e i file diventano vuoti senza un errore
• Cancellare per liberare: le cartelle fredde salgono su GCS e restano recuperabili
• Fidarsi del codice di uscita di gsutil per dichiarare un caricamento riuscito: va confrontato il numero di file
• Soglie di panico: se la pulizia riporta a 88 e larchiviazione parte a 90, il sistema non libera mai. Serve un obiettivo
• Spostare una cartella e creare un collegamento senza montare la destinazione: ho rotto la biblioteca per unora. Il collegamento va creato DOPO aver verificato che la destinazione risponda
• Un cost guard sulla spesa dei modelli che blocca ogni ripresa: i lavori che non usano modelli devono proseguire
• Riarmare il guard adesso: il credito e davvero a 2.62 USD, e una segnalazione vera
• Partire in modo DURO: se il controllo ha un difetto blocca tutti i modelli di colpo. Prima si osserva quante chiamate arriverebbero senza processo, poi si stringe
• Far scaricare il registro al gateway da GCS: 403, il bucket non e pubblico e non va reso tale
• Un secondo accesso MCP di scorta per i 503: il servizio non era rotto, era spento per risparmio. Due porte sullo stesso servizio addormentato danno lo stesso risultato
• Ampliare la VM per risolvere i 503: sono due cose diverse, Cloud Run e la VM
• Passare a DURO sulla base di zero rifiuti misurati prima che il controllo esistesse: e la stessa classe di falso successo di /vm/task e dello status 200
• Esentare per numero di processo: si esenta per NATURA del cliente, cosi non serve registrare i sorveglianti
• Esenzioni permanenti e non motivate: diventano buchi che nessuno ricorda di aver aperto
• Far decidere allanalisi chi esentare: propone i candidati con i numeri, concede Marco

Prossimo passo

• Domani 08:15 il primo rapporto con almeno 12 ore di osservazione: candidati, rifiuti, e la proposta su DURO
• Fra 30 giorni la revisione dellesenzione di oracolo-agent

lessico-canonico

Aggiornato 2026-08-13 19:49 UTC — dominio: knowledge

Obiettivo

Lessico canonico condiviso (idea Canonical ID da SGF): tabella BQ unica termine-ID-resa per lingua per eliminare la deriva terminologica fra traduttore live, RAIDA, Oracolo e wiki

Vincoli in vigore

• NULL dove la resa non e certa, mai fabbricare
• integrazioni nelle pipeline solo dopo test (traduttore = sistema live seminari) e dopo benchmark NotebookLM per lOracolo

Fatto (con prova)

• Creata isicnv_knowledge.lessico_canonico (15 colonne: id, lemma, categoria, invariante, resa it/fr/en/es/ru/pt, varianti_asr ARRAY, boost_asr, note, fonte)
• seed 33 termini estratti dalle patch reali del traduttore (/opt/translator/patch_glossary.py, patch_alch.py, patch_alch2.py, patch_hard.py): 8 latini invarianti con storpiature ASR note (athanor: latano/atanor/latano..., solve et coagula: sollievo alla colonna...), 5 marchi (Arkeos con 2 varianti note su 293 file), 11 nomi propri con rese standard in 6 lingue, 8 termini tecnici, 1 locuzione
• verificato con SELECT per categoria e spot-check

Prossimo passo

• 1) mining fonetico varianti Arkeos e altri marchi dai 9860 file trascrizione per completare varianti_asr 2) agent_gstt.py legge glossario+boost da export del lessico invece che hardcoded, con test feed_test.py prima del deploy 3) post-benchmark: query expansion Oracolo usa varianti_asr 4) giudice RAIDA verifica coerenza col lessico

oracolo-reindex

Aggiornato 2026-08-13 19:46 UTC — dominio: oracolo

Obiettivo

Reindicizzare la coda Biblioteca, ingerire il Traite dOr, riparare pipeline oracolo

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
• AUDIT RETRIEVAL vs checklist 7 tecniche stato dellarte: BM25 v3 OK con query expansion multilingue DeepSeek + boost wiki terms
• dense e5 OK peso 1.6
• fusione RRF k=60 OK
• cross-encoder BGE-reranker-v2-m3 OK con retry adattivo se best<0.30
• diversificazione per famiglia presente nel server (parametro diversifica, bm25_http_server.py riga 193) ma agent_kimi NON la richiede: rischio top-k ridondante dalla stessa opera
• nessuna strumentazione latenze per stadio

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

• DOPO fine benchmark NotebookLM (non prima, per non contaminare): 1) agent_kimi passa diversifica=true di default 2) timing per stadio nella risposta server 3) valutare HyDE-storico per lessico arcaico

paret-ai-pillar

Aggiornato 2026-08-13 18:12 UTC — dominio: hosting/siti + ai-search

Obiettivo

Costruire i pillar neurolinguistic.com per Ipnosi non verbale, Ipnosi con lo sguardo e Mesmerismus preservando SEO storico e preparando evidence graph

Vincoli in vigore

• MASTER v7.12
• testo pubblico mai da Claude: generazione via GLM e review
• nessuna nuova pagina se esiste URL valido
• snapshot/backup prima di ogni write
• pubblicazione solo dopo gate previsto dal cantiere benchmark-visibilita-ai

Fatto (con prova)

• Letto MASTER v7.12 e Piano Drive 14QM2efTg8YQwCp4LcF-gKfk5kMR1u0BzpX8IsbI8TFo. Ripreso cantiere benchmark-visibilita-ai. Audit live read-only: PID197 /ipnosi-non-verbale-tecnica-ed-esempi/ 200 self-canonical e storico dal 2013
• PID3576 /guardarmi-negli-occhi/ 200 self-canonical
• PID1848 /il-potere-dellocchio/ 200 self-canonical
• /mesmerismus/ 200 self-canonical ma contenuto molto sottile. Vecchio cluster attribuisce autorita 8218 a PID197, 5308 a PID3576, 3923 a PID1848. RAIDA e snapshot pre-build letti.

Provato ed escluso

• Nessuna modifica live eseguita. Non riutilizzare alla cieca potenzia_pillar.py: contiene pipeline precedente e testo con claim senza fonte.

Prossimo passo

• Classificare canonicalmente i tre cluster, fare snapshot WordPress recuperabile via accesso VM/FastComet, raccogliere canone+fonti indipendenti, generare bozze GLM preservando testo storico, review e collaudo offline
• poi gate pubblicazione.

migrazione-aigw

Aggiornato 2026-08-13 16:56 UTC — dominio: infrastruttura AI / gateway

Obiettivo

Instradare ogni lavoro AI sul fornitore piu economico che lo sa fare, dal gateway

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
• COST GUARD OPENROUTER ANALIZZATO: scattato 13/08 alle 18:45. NON per spesa eccessiva. Spesa giornaliera 1.33 su tetto 3.00, accelerazione 0.01 USD ogni 5 min. Ha scattato la condizione rest < CREDIT_MIN: credito residuo 4.99 contro soglia 5.00 USD. VERDETTO: guard APPROPRIATO, sta segnalando credito quasi esaurito non spreco. Spesa settimanale 35.68 USD
• Processi fermati dal guard: cita_service.py, svc oracle-agent, svc oracle-cita. Per riattivare: rm /opt/oracle/openrouter_guard.state
• PREZZI VERIFICATI 13/08/2026: Grok 4.6 uscito il 12/08 a 2.00 in / 6.00 out, contesto 500K, cache a 0.50. Grok 4.3 a 1.25/2.50 con contesto 1M. Grok 4.1 Fast a 0.20/0.50 con contesto 2M, il piu economico dei frontier. Grok Build 0.1 per codice a 1.00/2.00. ATTENZIONE: ogni tariffa RADDOPPIA sopra i 200K token di prompt
• OpenCode Zen: gateway curato senza ricarico, vende a costo e copre solo le commissioni di pagamento. Ricarica automatica di 20 USD sotto i 5. Alcuni modelli gratuiti a tempo (Grok Code Fast 1, DeepSeek V4 Flash). Endpoint compatibile OpenAI: opencode.ai/zen/v1
• LISTINO VIVO costruito: scripts/listino.py in cron alle 04:30. Legge i prezzi reali dal catalogo OpenRouter e sceglie, per ogni CLASSE DI LAVORO, il modello piu economico che soddisfa il requisito di contesto. Esito in gs state/listino_modelli.json
• CLASSI E VINCITORI AL 13/08: volume qwen3-8b 0.12/0.46, giudizio deepseek-chat 0.26/1.03, lungo glm-5.2 0.49/1.54, profondo glm-5.2 0.49/1.54, codice deepseek-chat 0.26/1.03. Costo misto calcolato come 75 per cento input piu 25 per cento output, il profilo dei nostri lavori
• SCOPERTO che il gateway aigw ha GIA un instradamento opencode (provider, opencode_models, oc_cost): era gia stato aggiunto
• SCOPERTO che Grok 4.1 Fast a 0.20/0.50 NON e su OpenRouter, esiste solo sullAPI xAI diretta. Ma non serve: qwen3-8b costa meno
• Su OpenRouter xAI offre: grok-4.6 e 4.5 a 2.00/6.00 ctx 500K, grok-4.3 e 4.20 a 1.25/2.50 ctx 1M e 2M, grok-build-0.1 a 1.00/2.00
• ATTENZIONE: le tariffe xAI RADDOPPIANO sopra i 200K token di prompt, e con contesti da 1-2M e facile inciamparci

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
• Alzare CREDIT_MIN o disattivare il guard per far ripartire i servizi: nasconderebbe il problema vero, che e il credito in esaurimento
• Passare tutto a Grok 4.6 per riflesso: costa il doppio in uscita rispetto a Grok 4.3, ed e posizionato per codice e agenti non per uso generale
• Passare a Grok 4.6 per riflesso: 2.00/6.00 contro 1.25/2.50 del 4.3, e il doppio in uscita per un modello posizionato su codice e agenti
• Aprire una fatturazione xAI diretta per Grok 4.1 Fast: qwen3-8b su OpenRouter costa gia meno

Prossimo passo

• Collegare gli alias di classe al gateway: gli script chiedono volume o giudizio invece del nome del modello, cosi cambiare fornitore e una riga nel listino e non 289 modifiche
• Misurare il risparmio reale su una settimana confrontando calls.jsonl prima e dopo

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

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