Cantieri aperti: differenze tra le versioni
| [versione verificata] | [versione verificata] |
handoff automatico |
handoff automatico |
||
| (29 versioni intermedie di uno stesso utente non sono mostrate) | |||
| Riga 7: | Riga 7: | ||
== Cantieri attivi == | == Cantieri attivi == | ||
=== video-proxy-pipeline === | |||
''Aggiornato 2026-08-16 16:33 UTC'' — dominio: video / infrastruttura | |||
; Obiettivo : Fase 1: proxy 1080p dei 40TB (locali in _proxy, upload differito) + significato su cloud; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; strato scene+significato; 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). | |||
* CENSIMENTO ESTESO (richieste Marco): (1) match RENAME-TOLERANT operativo: vista v_cloud_vs_dischi_bysize incrocia cloud e dischi per SOLA dimensione esatta -> gia trovati 12 file rinominati-ma-identici + 57 stesso nome, con appena 2 dischi catastati | |||
* md5 disponibile lato Drive per conferme forti. (2) Census esteso a WeVideo_Export (i media in arrivo da WeVideo avranno md5 gratis da Drive) e messo a CRON settimanale lun 05:30 -> i nuovi arrivi si censiscono da soli. (3) ATTENZIONE COORDINAMENTO: tabella drive_video_census riscritta da altro processo (probabile sessione Cowork WeVideo, schema path/top_folder/ext) -> il mio census con md5 spostato su drive_uploader_census (namespace separato, viste aggiornate). (4) Census Yandex IN CORSO (listing WebDAV lento, tabella placeholder pronta, si carica da solo al termine, log yandex_census.log). Quadro Marco: ~6-7TB gia in cloud (Drive 3.19TB + Yandex in conteggio + WeVideo in arrivo) -> materiale per primi test Fase 2 quasi pronto. | |||
* DIAGNOSI DEFINITIVA UPLOAD: linea casa Marco ~0.1MB/s effettivi (prova: 30MB totali su box in ore, audio 61MB in timeout a 605s, upload 94min morto in EOF). Marco aveva ragione: il collo E' l'upload - ma della linea, non del provider. PIVOT v4.0 PUBBLICATA (sha c7c2da5c): SIGNIFICATO SEPARATO DAI PIXEL - upload proxy DIFFERITO (config proxy_upload:false, riattivabile via config push), i proxy restano al sicuro in _proxy sui dischi (rigenerabili+spedibili in blocco quando la linea si risolve) | |||
* audio+miniature (briciole) continuano a fluire -> trascrizioni e strato semantico NON si fermano. CENSUS YANDEX COMPLETO: 1858 video = 1.88TB (24 stesso nome + 11 rinominati vs dischi). TOTALE CLOUD CONFERMATO: Drive 3.19TB + Yandex 1.88TB = 5.07TB + WeVideo in arrivo = i 6-7TB stimati da Marco. Da chiedere a Marco: PC in Wi-Fi o cavo? (fix banale possibile) | |||
* alternative: sessione-fibra periodica coi dischi, o secondo PC presso connessione veloce. | |||
; 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) DOMANDA A MARCO: PC su Wi-Fi o cavo ethernet? speedtest? 2) se linea risolta: riattivare proxy_upload via config push e smaltire arretrato 3) trascrizioni/vision continuano sui 5TB cloud + audio in arrivo 4) primi test ricerca-nel-parlato fattibili ORA | |||
=== benchmark-visibilita-ai === | === benchmark-visibilita-ai === | ||
''Aggiornato 2026-08-14 | ''Aggiornato 2026-08-16 14:34 UTC'' — dominio: ai-search | ||
; Obiettivo : | ; Obiettivo : PILLAR 8 PASSI MAGNETICI live su URL storico 2511 | ||
; Vincoli in vigore : | ; Vincoli in vigore : | ||
* testo pubblico mai da Claude (watermark) | * testo pubblico mai da Claude (watermark) | ||
| Riga 32: | Riga 88: | ||
* 3576: 94/82 | * 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 | * 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) | |||
* 16/08: nomi confermati BACCI (passi) e RACANELLI (tre stanze). PASSI MAGNETICI pubblicato AGGIORNANDO il post 2511 del 2018 (URL con 7 anni di anzianita', backup pre_pillar_*): Bacci, stato parasimpatico + degagement, Gazette fourmillement, video eysSdCL7S1Q embed, convincer palme, 2 domande, 0 negazioni, misurabilita' vs induzioni verbali, link da 11285/1582/11348/11336, due motori ok. Archivi aggiornati: convincer marco-passi, differenziatori stato-parasimpatico/passi-misurabili/scienza-passi. Trascrizione GDoc 1ngF5GuujGkBx4RNep2LIMO3NXzgkLM2v2uf2iEop9oU | |||
; Provato ed escluso : | ; Provato ed escluso : | ||
* ipotesi PT-forte smentita dai dati | * ipotesi PT-forte smentita dai dati | ||
; Prossimo passo : | ; Prossimo passo : | ||
* | * P9 SONNAMBULISMO (7 citazioni pronte) e P10 SILENZIO (4 pronte, Racanelli/tre stanze/sala dei miracoli) al prossimo continua | ||
* | * trascrizioni definitive P9/P10 | ||
* | * serie M marcoparet.com (M1/M2 questionari creati, attende risposte + publishing path) | ||
=== harness-standard === | === harness-standard === | ||
''Aggiornato 2026-08- | ''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 | ; Obiettivo : Sostituire il MASTER READ ORDER monolitico con un harness gerarchico e togliere Marco dal ruolo di loop di esecuzione | ||
| Riga 227: | Riga 304: | ||
* 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 | * 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 | * 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 : | ; Provato ed escluso : | ||
* Adottare ahar / agentharnesses-cli: presuppone Claude Code su repo locale, Marco lavora da smartphone via route CC | * Adottare ahar / agentharnesses-cli: presuppone Claude Code su repo locale, Marco lavora da smartphone via route CC | ||
| Riga 286: | Riga 392: | ||
* Soglie di panico: se la pulizia riporta a 88 e larchiviazione parte a 90, il sistema non libera mai. Serve un obiettivo | * 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 | * 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 : | ; 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 === | === lessico-canonico === | ||