Cantieri aperti: differenze tra le versioni
| [versione verificata] | [versione verificata] |
handoff automatico |
handoff automatico |
||
| (14 versioni intermedie di uno stesso utente non sono mostrate) | |||
| Riga 7: | Riga 7: | ||
== Cantieri attivi == | == Cantieri attivi == | ||
=== video-proxy-pipeline === | |||
''Aggiornato 2026-08-18 22:23 UTC'' — dominio: video / infrastruttura | |||
; Obiettivo : Fase 1: proxy 1080p dei 40TB (locali, upload auto-adattivo) + significato su cloud; Fase 2 editor web; Fase 3 conform 4K; Fase 4 piattaforme; 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. | |||
* AVANZAMENTO FORTE: INTENSO 212/1526 (13.9%, raddoppiato - ora su file OSMO piccoli), Maxtor 119/2944, 102 audio + 141 thumb su Yandex, coda collassata a 23 (pivot v4.0 efficace). v4.1 PUBBLICATA (sha ad5740d5): SPEED-TEST AUTOMATICO ogni 2h (8MB reali verso la box) con AUTO-DECISIONE: >=0.35MB/s -> upload proxy si ATTIVA da solo (log 'LINEA SUFFICIENTE') | |||
* sotto soglia resta differito. Marco provera' il CAVO ethernet: nessun riavvio necessario, il test se ne accorge da solo entro 2h max (o al primo test post-push). Se anche col cavo <0.35: la linea e' il limite fisico -> piano sessione-fibra o secondo PC. | |||
* VPN esclusa da Marco (nessuna sul PC | |||
* sul telefono si - screenshot con VPN attiva, upload speedtest mai completato, download 75.47 vicino al PC = aria wifi buona). Sospettato principale: SCHEDA WI-FI DEL PC (radio vecchia/2.4GHz/driver). v4.2 PUBBLICATA (sha 002ab005, salta 4.0->4.2): DIAGNOSI WI-FI REMOTA - all'avvio del thread velocita l'agente logga 'netsh wlan show interfaces' (SSID, banda, segnale, velocita di aggancio, canale) + tachimetro 8MB ogni 2h con auto-attivazione proxy >=0.35MB/s. Le due misure insieme daranno il verdetto: aggancio radio basso = colpa scheda PC (fix: adattatore USB wifi/ethernet 10-15 euro o trasloco PC vicino al router) | |||
* aggancio alto ma upload basso = linea/contratto. | |||
* PRIMO RIAVVIO REMOTO RIUSCITO via control.json (agente rinato 15:27 post cambio-rete di Marco: da SFR_A570_EXT a rete principale). BUG SCOPERTO dal riavvio: sb_key resa sola-lettura da icacls al primo avvio -> ai riavvii open('w') = PermissionError -> sb_setup falliva -> Storage Box E TACHIMETRO spenti (per questo nessun Test velocita finora!). v4.3 PUBBLICATA (sha 4694a2e2): riusa la chiave esistente su PermissionError. Al prossimo confine clip: push v4.3 -> boot -> diagnosi Wi-Fi (verificare SSID senza _EXT) + tachimetro finalmente operativo + eventuale auto-attivazione proxy. Upload pre-cambio: 0.02MB/s (baseline peggiorata, ma misure a cavallo dello switch). | |||
* SVOLTA RETE: screenshot Marco 19/08 00:03 conferma Wi-Fi ora SFR_A570 5GHz 802.11ac, TX 780Mbps RX 585 (era _EXT 2.4GHz) - il ripetitore era il problema di rete, NordVPN rimossa, Windows riavviato. Tachimetro falliva per BUG MIO: il warning ssh 'Permanently added to known hosts' (primo collegamento) trattato come errore. v4.4 PUBBLICATA (sha f3d292d5): (1) FIX ssh/scp LogLevel=ERROR + errori valutati SOLO su returncode | |||
* (2) IDEA MARCO IMPLEMENTATA: esclusione cartelle palesemente estranee dopo la mappatura - EXCLUDE_PAT (film/serie/musica/call recorder/downloads/appdata/windows/temp Pc/backup pc/whatsapp/telegram/screenshot/pictures/onedrive), con riepilogo a log 'Saltati N video estranei (X GB)' | |||
* testata su casi reali (Il padrino ESCLUSO, PARET.MTS TENUTO). PRIVACY: stop upload registrazioni consulti privati di Ilaria. Riavvio remoto ordinato per applicare subito. | |||
* BUG PUSH TROVATO E CORRETTO (Marco chiedeva 'non puoi fare riavvio push?'): il riavvio da control.json veniva eseguito PRIMA del controllo versione -> l'agente si rilanciava sempre sulla STESSA versione (bloccato a v4.3 mentre la wiki serviva 4.4/4.5/4.6) | |||
* inoltre ogni errore di aggiornamento era ingoiato da un except silenzioso. v4.7 PUBBLICATA (sha in wiki): ordine invertito (PRIMA aggiorna, POI eventuale riavvio) + ogni fallimento di aggiornamento ora e' loggato con tipo eccezione | |||
* control.json azzerato. 2 assert (priorita aggiornamento su riavvio, errore visibile su PermissionError). NOTA: il .bat di avvio scarica sempre l'ultima versione -> un chiudi/riapri manuale porta comunque all'ultima. ERRORI TRANSCODIFICA MASSIVI su Maxtor (MTS e anche MP4 di altre cartelle, quindi NON e' il formato): sospetto forte DISCO PIENO | |||
* la v4.6/4.7 mostra il motivo ffmpeg reale e dirotta i proxy su C: sotto i 25GB liberi. | |||
* CAUSA ERRORI TRANSCODIFICA TROVATA (grazie a v4.7 in produzione + screenshot Marco): MAXTOR PIENO 0.0GB. Causa di design MIA: i proxy si scrivono in _proxy SULLO STESSO disco letto e non venivano mai cancellati (dovevano sparire dopo l'upload, ma gli upload erano fermi). Nessun dato di Marco toccato. Anche C: ha solo 23GB. Inoltre v4.7 ha mostrato il vero motivo del tachimetro fallito: la shell della Storage Box non digerisce le virgolette (scp: dest open: No such file or directory). v4.9 PUBBLICATA (sha b21b1525): (1) upload proxy via SFTP BATCH in una sola sessione - crea tutti i livelli con -mkdir (errori ignorati) e fa put, gestisce spazi nei path | |||
* PROVATO REALMENTE sulla box (cartella 'TEST SPAZI' creata + 8MB caricati) | |||
* (2) CLEANUP: proxy locale cancellato subito dopo upload riuscito -> il disco si libera da solo | |||
* (3) fallback proxy su C: gia con 15GB liberi. FUNZIONANTI in v4.7: esclusioni (891 video estranei saltati, 8.2GB), cartelle_dubbie (72 da confermare: videos/congres pavlina/ULTIMO GIORNO/OTHER 39, testimonial 8, recastly 5...), guardia spazio, allerte v4.8. Wi-Fi ora 866Mbps. | |||
* CAUSA ERRORI TRANSCODIFICA CONFERMATA dal log v4.7: 'spazio quasi esaurito (0.0GB sul disco)' - i proxy venivano scritti in _proxy SULLO STESSO disco letto e mai cancellati (dovevano esserlo dopo l'upload, ma gli upload erano fermi) -> Maxtor saturato. Nessun file di Marco toccato. Trovato anche il perche' upload/speedtest fallivano: la shell della Storage Box non digerisce mkdir con virgolette su path con spazi. v4.9+v5.0 PUBBLICATE (sha b21b1525 -> nuova): (1) upload via SFTP BATCH (una connessione: -mkdir per livello + put, spazi gestiti) - PROVATO SUL CAMPO dalla VM: cartella 'TEST SPAZI' creata e 8MB caricati | |||
* (2) PULIZIA proxy locale dopo upload riuscito (cleanup_after_upload) -> il disco si libera da solo | |||
* (3) REGOLA MARCO: in emergenza spazio la scala e' disco origine -> ALTRO DISCO ESTERNO collegato (>50GB, es. INTENSO) -> PC di Marco SOLO se tutti pieni, con allerta email | |||
* (4) sistema ALLERTE v4.8: agent_alerts BQ + email isicnv@gmail.com + flush log immediato su primo errore, 3/10/30 errori consecutivi, spazio esaurito, aggiornamento fallito, 5/25/100 upload falliti (anti-ripetizione 2h). Assert passati su tutto. Wi-Fi ora 866Mbps (5GHz). Saltati 891 video estranei (8.2GB) su Maxtor + 72 clip in 8 cartelle dubbie registrate. | |||
* INCIDENTE E RIPARAZIONE: mia sostituzione di codice in v4.9 aveva cancellato net_diag e speed_loop -> agente CRASH all'avvio (NameError, fermo ~40 min). v5.1 ripristino + ASSERT ANTI-REGRESSIONE ora in pipeline di deploy (AST: nessuna chiamata a funzione inesistente, blocca la pubblicazione). DECISIONI MARCO 19/08: (1) cartelle dubbie CONFERMATE TUTTE (72 su Maxtor: videos/congres pavlina, testimonial, recastly, ANEB/DORA, enneagramma PNL3, GOOGLE DRIVE, fotosequenze HANA) - si lavorano tutte, restano solo tracciate in BQ cartelle_dubbie | |||
* (2) REGOLA DI CANCELLAZIONE codificata: l'agente puo' rimuovere SOLO file creati da se' (proxy/audio/thumb) e SOLO se l'originale sul disco esiste ancora (sono rigenerabili=temporanei) | |||
* mai file utente, mai i registri manifest/uploaded/media.csv | |||
* (3) PRIORITA SPAZIO: disco origine -> altro disco esterno (INTENSO) -> PC di Marco solo ULTIMA RISORSA con email. v5.2 PUBBLICATA (sha 1a579beb) con libera_spazio() che pulisce Maxtor automaticamente sotto i 25GB liberi (target 45GB), assert stringenti superati (file con originale mancante NON toccato, registri intatti). | |||
; 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) verificare v5.2 attiva, spazio liberato su Maxtor e ripresa transcodifiche 2) primo Test velocita via sftp (metodo verificato sulla box) -> possibile auto-attivazione proxy 3) allerte email al primo errore (v4.8+) 4) trascrizioni/vision | |||
=== harness-standard === | === harness-standard === | ||
''Aggiornato 2026-08- | ''Aggiornato 2026-08-17 15:01 UTC'' — dominio: architettura / knowledge base | ||
; Obiettivo : | ; Obiettivo : Harness gerarchico e Marco fuori dal loop di esecuzione | ||
; Vincoli in vigore : | ; Vincoli in vigore : | ||
* La gerarchia deve SOSTITUIRE substrati esistenti, mai affiancarsi: oggi ne esistono 7 paralleli | * La gerarchia deve SOSTITUIRE substrati esistenti, mai affiancarsi: oggi ne esistono 7 paralleli | ||
| Riga 229: | Riga 310: | ||
* chiusura.py esteso con il gruppo SBLOCCO: appena tocchi, ti do poi il link, mi serve una tua conferma. Provato sulla frase reale di quella chat, la intercetta | * chiusura.py esteso con il gruppo SBLOCCO: appena tocchi, ti do poi il link, mi serve una tua conferma. Provato sulla frase reale di quella chat, la intercetta | ||
* Avviso globale diramato a tutti i processi attivi | * Avviso globale diramato a tutti i processi attivi | ||
* HERMES DAILY GIA ESISTE: /home/claudeuser/hermes/hermes_daily.py v0.1 del 28/05, cron ogni sera alle 19:00, manda un digest con articoli scored e friction recap. Nella sua stessa intestazione: matching engine + proposals arriveranno in F3. La parte proposte non era mai stata costruita | |||
* COSTRUITA LA F3: scripts/hermes_migliorie.py, cron alle 19:30, dopo il digest | |||
* VINCOLO DI PROGETTO: le proposte devono nascere da COSA E FALLITO DAVVERO. Larticolo Harness-R1 misura che i modelli fissi propongono patch plausibili che PEGGIORANO. Qui ogni proposta deve CITARE la riga di prova da cui nasce, e chi non cita viene scartato prima di arrivare a Marco | |||
* IL PACCHETTO DI PROVE si compone da solo: campo escluso dei cantieri (i vicoli ciechi gia pagati), log del riparatore, sentinella notturna, stato dei dischi, processi fermi, costi per cliente dal gateway | |||
* PRIMA ESECUZIONE RIUSCITA: 3 proposte, tutte ancorate a una prova reale. Sostituire il reindex via /vm/task con job.py o cron | |||
* risolvere il fallimento muto dei trasferimenti sopra 90KB usando biblioteca/ingest.py | |||
* controllo hash sui duplicati byte-identici nei TIF marchi | |||
* Non esegue nulla: propone, cita, e lascia decidere | |||
* APPROVATE ED ESEGUITE le prime due proposte di Hermes Migliorie | |||
* 1) REINDEX ORACOLO IN CRON sulla VM, lunedi 03:40, scripts/reindex_oracolo.sh. Toglie ChatGPT dal giro: prima dipendeva da un task settimanale esterno ed e rimasto fermo dal 19 luglio al 9 agosto senza che nessuno lo notasse. RISOLTA ANCHE LA RACE CONDITION: il flag si svuota SOLO delle righe fotografate allinizio, quelle aggiunte durante lesecuzione restano in coda. Se fallisce il flag resta pieno e parte lavviso Telegram. Provato: coda vuota, uscita pulita | |||
* 2) SCRITTURA VERIFICATA: scripts/scrittura.py. scrivi() scrive, rilegge, confronta lo sha256 e ALZA se non torna | |||
* controlla anche lo spazio PRIMA di scrivere. verifica() da riga di comando per gli script bash. Provato su tre casi: file sano ok, file vuoto rifiutato, dimensione sbagliata rifiutata | |||
* COLLEGATO a migra_aigw.py e a spingi_processi.sh, che ora non spinge un file vuoto | |||
* MASTER v7.14: la regola V si estende alle scritture | |||
* NON FATTA la terza proposta (hash sui duplicati TIF): poco valore, rimessa in coda | |||
* API ANTHROPIC: verificato che NESSUNO script attivo in cron chiama api.anthropic.com. I 4 file che contengono lindirizzo (ai_helper, paret_common, telegram_bot_handler e il suo backup) sono tutti fuori cron, codice residuo | |||
* MA IO NE AVEVO INTRODOTTO UNO: consenso.py usava anthropic/claude-haiku-4.5 come secondo revisore, e il listino aveva claude-sonnet-5 fra i candidati. Passavano da OpenRouter quindi non servivano chiavi Anthropic, ma consumavano il credito gia a 2 dollari. Sostituito con qwen3.8-max, candidati anthropic nel listino: 0 | |||
* HERMES DAILY: trovato che andava in errore OGNI NOTTE, fetch_data restituiva None per il 503 del CC, il digest non si costruiva, e mandava lemail lo stesso con HTTP 200. Marco riceveva mail vuote con invio dichiarato riuscito. Corretto: se i dati non arrivano manda un avviso esplicito invece di un digest vuoto. Destinatario spostato da marcoparet@gmail.com a isicnv@gmail.com. Backup hermes_daily.py.bak_20260817 | |||
* MIGLIORIE anche via mail a isicnv@gmail.com, verificato nel log | |||
* NUOVO SCHEMA rilevato in chiusura.py: la decisione gia presa e annullata dal punto interrogativo. Intanto proseguo con X e giusto, Intanto proseguo con X? ferma tutto per un carattere. MASTER v7.15 STEP 5-F | |||
* capability_scan funziona bene: 40 capacita censite, 4 token, 7 chiavi api | |||
* ATTENZIONE: fetch_rss.log e a 5,9 MB e cresce senza rotazione | |||
* MODEL SWITCHER nel gateway. Prima il gateway aveva chiavi, instradamento per fornitore e rifiuto dei costosi col guard scattato, ma chi chiamava doveva NOMINARE il modello. Ora si chiede una CLASSE (volume, giudizio, lungo, profondo, codice) e sceglie lui, leggendo /opt/aigw/listino.json spinto dalla VM ogni minuto | |||
* RETROCESSIONE INVECE DI RIFIUTO: col guard scattato sceglie lalternativa piu economica della stessa classe invece di bloccare. Meglio un modello modesto che un lavoro fermo | |||
* TRACCIA: ogni chiamata registra chiesto, servito e come. Esempio reale dal log: giudizio -> deepseek-chat, classe giudizio guard attivo retrocesso al piu economico | |||
* DIFETTO CORRETTO alla prima prova: il listino usa nomi OpenRouter (deepseek/deepseek-chat) mentre i fornitori diretti vogliono il nome nudo. Due classi su tre davano 400. Aggiunta normalizza_per_provider | |||
* PROVA: volume 200, giudizio 200, profondo 503 per OpenCode giu, non per il switcher | |||
* Backup aigw.py.bak_switcher e .bak_norm | |||
* CAUSA TROVATA del perche le chat chiedono a Marco cose gia note al sistema: il registro isicnv_properties.registry ha un campo wiki_page per 520 proprieta su 535, ma il campo dice solo DOVE la pagina dovrebbe stare. Per greenagritainment.com il registro prometteva la pagina e sulla wiki NON ESISTEVA. Nessuna chat poteva trovarla | |||
* SITO GIUSTO TROVATO: due installazioni WordPress sullo stesso account HostGator. public_html admin marco, e greenagritainment.com admin ad-agri e marco-agri tema agronix. La chat precedente lavorava alla cieca senza saperlo | |||
* ESEGUITE LE 4 COSE lasciate a mano: password di ad-agri e marco-agri ruotate via wp-cli, sessioni distrutte, plugin verificati (zero da aggiornare), integrita controllata. Core WordPress verifica, 28 plugin su 31 verificano contro i checksum ufficiali, functions.php del tema pulito, nessun PHP sospetto in uploads. Il contact-form-7 versione piu alta e regolare, verifica contro i checksum | |||
* Wordfence NON ha il sottocomando wp wordfence scan: la scansione va dal pannello | |||
* CREATO scripts/wiki_proprieta.py: verifica che le pagine promesse dal registro esistano, e crea le mancanti con lo schema Identita Accessi Stato TODO History. Cron martedi 05:00 | |||
* PAGINA greenagritainment.com creata e COMPILATA con tutto il verificato oggi | |||
* MASTER v7.16 STEP 3: prima di toccare un sito o un account si legge la sua pagina wiki, e se manca la si crea a fine lavoro | |||
* INFORMAZIONI SALVATE in memoria CC: skill_1786978867715_xjzml5 scheda greenagritainment.com con le due installazioni WP, accessi, cronologia incidente ed esito verifica | |||
* rule_1786978868095_tvz8bu la regola wiki-prima | |||
* skill con lelenco aggiornato degli strumenti sulla VM. Piu la pagina wiki compilata e il MASTER v7.16 | |||
; 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 299: | Riga 418: | ||
* Far decidere allanalisi chi esentare: propone i candidati con i numeri, concede Marco | * Far decidere allanalisi chi esentare: propone i candidati con i numeri, concede Marco | ||
* Trattare il caso come dimenticanza o pigrizia: e un errore di ordinamento, e si corregge con una regola di ordinamento non con un richiamo | * Trattare il caso come dimenticanza o pigrizia: e un errore di ordinamento, e si corregge con una regola di ordinamento non con un richiamo | ||
* Costruire Hermes Daily da zero: esisteva gia, mancava solo la F3 | |||
* Proposte di buone pratiche generiche: senza citazione della prova vengono scartate automaticamente | |||
* Eseguire la proposta cosi come formulata: diceva sostituire /vm/task con job.py, ma /vm/task lho gia riparato col wrapper il 09/08. Il problema vero era piu grande, la dipendenza da una chat esterna | |||
* Curare il sintomo dei 90KB: il male era che la scrittura fallisse in silenzio, non la dimensione | |||
* Tenere modelli Anthropic nel listino e nei revisori: Marco non usa quellAPI e il credito OpenRouter e a 2 dollari | |||
* Rifiutare col guard scattato: ferma il lavoro. Meglio retrocedere | |||
* Chiedere a Marco informazioni sul sito: erano tutte ricavabili da wp-cli e dal registro. Laccesso cera, wp-cli era installato | |||
; Prossimo passo : | ; Prossimo passo : | ||
* Domani 08:15 | * Lanciare wiki_proprieta.py --controlla su tutte le 286 website per contare le pagine promesse mancanti | ||
* Scansione Wordfence dal pannello | |||
* Domani 08:15 rapporto registro processi | |||
=== benchmark-visibilita-ai === | === benchmark-visibilita-ai === | ||
''Aggiornato 2026-08- | ''Aggiornato 2026-08-17 08:40 UTC'' — dominio: ai-search | ||
; Obiettivo : | ; Obiettivo : Chat 'brand dr. Paret' CHIUSA (16/08 sera). Prossima chat: QUESTIONARI per nuove pagine (neurolinguistic + marcoparet.com) | ||
; Vincoli in vigore : | ; Vincoli in vigore : | ||
* testo pubblico mai da Claude (watermark) | * testo pubblico mai da Claude (watermark) | ||
| Riga 353: | Riga 480: | ||
* sitemap neurolinguistic inviata | * sitemap neurolinguistic inviata | ||
* Indexing API su 12 pagine cluster + sonnambulismo. P9 SONNAMBULISMO: pubblicato da chat parallela come 11505 (OTTIMO: 0 negazioni, plesso solare, FAQ ok) — questa chat ha completato: link da 11285, due motori lanciato, indexing. P10 SILENZIO: PRESO IN CARICO QUI (Racanelli/tre stanze/sala miracoli, territorio-vs-mappa, DMN, Broca, oltre-le-AI) | * Indexing API su 12 pagine cluster + sonnambulismo. P9 SONNAMBULISMO: pubblicato da chat parallela come 11505 (OTTIMO: 0 negazioni, plesso solare, FAQ ok) — questa chat ha completato: link da 11285, due motori lanciato, indexing. P10 SILENZIO: PRESO IN CARICO QUI (Racanelli/tre stanze/sala miracoli, territorio-vs-mappa, DMN, Broca, oltre-le-AI) | ||
* Sessione 16/08: P8 passi (2511 rinnovato, coda entita' ripristinata, box scuola, complementarita', anima v2), P9 sonnambulismo 11505 (chat parallela + rifiniture qui), P10 silenzio 11512 (Racanelli via Bacci - fact_1786919344548). AGENTE ANIMA in pipeline (manifest v3: scopo, sottile, dolori forum impliciti, complementarita'). GSC: 15 domini verificati (token-any-gsc-admin, TXT sui 4 cPanel, zone map 112), sitemap + indexing 14 URL. Catalogo biblioteca 2761 voci (isicnv_knowledge.biblio_catalogo). LEARNING: wp post update MAI via stdin - sempre file+scp+verifica (learning_1786902279558) | |||
; Provato ed escluso : | ; Provato ed escluso : | ||
* ipotesi PT-forte smentita dai dati | * ipotesi PT-forte smentita dai dati | ||
; Prossimo passo : | ; Prossimo passo : | ||
* | * 1) hub biblioteca-magnetica + 10 pagine-periodo | ||
* 2) anima retroattiva cluster + coda entita' regia (schema+attribuzione ovunque, referenze solo ammiraglie) | |||
* anima retroattiva cluster | * 3) pagine satellite domini tematici (franzantonmesmer, miltonerickson, hypnotisme, personalmagnetism) | ||
* 4) marcoparet.com publishing path + serie M (M1/M2 GDoc in attesa risposte) | |||
* 5) trascrizioni P9/P10 GDoc | |||
* 6) misura lunedi' | |||
* | |||
* | |||
* | |||
* | |||
=== lessico-canonico === | === lessico-canonico === | ||