Cantieri aperti: differenze tra le versioni

=== fabbrica-ingresso-config-vincente ===

''Aggiornato 2026-09-16 20:12 UTC'' — dominio: pillar

; Obiettivo : Dare a fabbrica_pagine.py un ingresso per i parametri della configurazione vincente del benchmark (boost_ids, priorita_max, max_regole, famiglie_escluse, prompt editor, det_dopo) cosi che il guadagno misurato arrivi in produzione; oggi la fabbrica compone le regole per conto suo e non chiama compila_regole.py

* Backup di fabbrica_pagine.py prima di toccarlo

* nessuna spesa modello per il collegamento

* la config da usare e la migliore in pillars/benchmark_regole/STATO.txt dopo il job benchmark_regole_ottimizza_0916

* verificare con una corsa --una che la pagina passi i gate

* nessuna pubblicazione

* 16/09: censimento 94 controlli (43 orfani), verificato che fabbrica e compila_regole ignorano la config vincente

* lanciato benchmark ottimizza budget 2 USD sulle regole aggiornate

* python3 job.py --status benchmark_regole_ottimizza_0916

* poi leggere fabbrica_pagine.py riga 56-110 e innestare la lettura di pillars/benchmark_regole/config_<migliore>.json

=== pilota-custode-flash ===

''Aggiornato 2026-09-16 19:58 UTC'' &mdash; dominio: infrastruttura

; Obiettivo : Pilota 3 giorni: V4.1 Flash e GLM-5.3 Flash come custode R103, misurati dal registro modelli

* non cambiare i default prima di 5 prove per modello

* 16/09: modelli_ledger.py

* si_common.model_json misura e sceglie per ruolo

* riprendi_chat usa i Flash via OpenRouter

* fix reasoning effort low + tetto 2000

* pilota: dopo il fix 6/6 verdetti validi, GLM 3.3s, V4.1 6.2s, gemini 2.8s

* python3 /home/claudeuser/sovra/modelli_ledger.py classifica custode

=== mail-fasce-individuali ===

''Aggiornato 2026-09-15 20:27 UTC'' &mdash; dominio: email

; Obiettivo : Spedizione italiana per fascia oraria individuale con un solo comando deterministico

* Passo 6 spedisce davvero: solo con ok di Marco (R102) e con lo spec della lettera. Blacklist Mailwizz: alcune righe scartate al load (max_bad_records), da controllare quante.

* gate_fasce.py installato e provato (rc 95 su spedizione italiana generale senza fasce)

* regola scritta in testa a mail_engine.py e nel registro pipeline MAIL-1

* hook in exec_mailwizz e exec_getresponse

* backup mail_engine.py.bak_gate_fasce_20260915T200753

* gate_fasce.py in mail_engine

* spedizione_fasce.py 7 passi con checkpoint BQ

* passi 0-4 eseguiti sul run it15set (aperture sincronizzate fino a stasera)

* wiki ops Spedizione_a_fasce_orarie

* memoria CC procedura_1789503820532_0fja44

* Prima spedizione reale: python3 /home/claudeuser/scripts/spedizione_fasce.py --run <id> --letter <letter_id> --fino 4

* poi con lo spec: --spec spec.json --da 5 --fino 6 . Passi 5-6 mai ancora provati in produzione: provarli prima su lista test.

=== gate_log_accessi_pipeline ===

''Aggiornato 2026-09-15 08:49 UTC'' &mdash; dominio: CC/gate/tracciabilita

; Obiettivo : Ogni comando delle chat ricostruibile in BQ (chi, richiesta, pipeline); chat bloccata ripresa da v_sessioni_stato

* Cloud Run sheets-connector: solo gate_deploy.sh, reversibile

* non toccare la sessione mcpchatgpt attiva

* FATTO: (1) tracce.py ora scrive message_id (CURRENT token della sessione) in ogni riga

* colonna aggiunta a isicnv_workflows.tracce. (2) Vista v_sessioni_stato = chat_sessions_log + tracce + human_messages_log con stato CHIUSA/ATTIVA/INTERROTTA/APERTA_SENZA_COMANDI, ultima richiesta, ultimo comando, next_action. DIAGNOSI (dati 8-15/09): a) tutte le chat ChatGPT via MCP condividono UNA sessione al giorno (S...-mcpchatgpt-...): 8 sessioni, 1629 comandi, 173 falliti, un solo CURRENT message token -> comandi di chat diverse mischiati, impossibile capire quale chat si e' bloccata. b) chat_journal START ha dettaglio vuoto: lo scopo dichiarato a /session/open e la pipeline_obbligatoria restituita NON vengono loggati. c) campo cantiere vuoto sul 100% delle righe tracce. d) END loggato in 6 sessioni su ~200: 'bloccata' e 'finita' sono indistinguibili. e) righe GATE con session_id spazzatura ('pathlib','100','%s'): bug del gatekeeper. RESTA (Cloud Run sheets-connector, serve deploy con gate_deploy.sh): 1) /session/open deve scrivere in chat_sessions_log.dettaglio JSON {scopo, pipeline_ids, chat} e in una tabella isicnv_workflows.session_pipeline (session_id, ts, scopo, pipeline_id) -> da cui si vede quali processi usano quali pipeline. 2) MCP ChatGPT: session id per chat (nonce per conversazione), non per giorno. 3) gate.sh: passare --cantiere/scopo a tracce.py log. 4) heartbeat: cron ogni 30 min che marca INTERROTTA in chat_journal le sessioni ATTIVA senza comandi da >60 min, cosi' Telegram/agente le riprende con last_next_action. 5) fix session_id spazzatura nelle righe GATE. DIAGNOSI (dati 8-15/09): a) tutte le chat ChatGPT via MCP condividono UNA sessione al giorno (S...-mcpchatgpt-...): 8 sessioni, 1629 comandi, 173 falliti, un solo CURRENT message token -> comandi di chat diverse mischiati, impossibile capire quale chat si e' bloccata. b) chat_journal START ha dettaglio vuoto: lo scopo dichiarato a /session/open e la pipeline_obbligatoria restituita NON vengono loggati. c) campo cantiere vuoto sul 100% delle righe tracce. d) END loggato in 6 sessioni su ~200: 'bloccata' e 'finita' sono indistinguibili. e) righe GATE con session_id spazzatura ('pathlib','100','%s'): bug del gatekeeper.

; Provato ed escluso :

* niente

; Prossimo passo :

* RESTA (Cloud Run sheets-connector, serve deploy con gate_deploy.sh): 1) /session/open deve scrivere in chat_sessions_log.dettaglio JSON {scopo, pipeline_ids, chat} e in una tabella isicnv_workflows.session_pipeline (session_id, ts, scopo, pipeline_id) -> da cui si vede quali processi usano quali pipeline. 2) MCP ChatGPT: session id per chat (nonce per conversazione), non per giorno. 3) gate.sh: passare --cantiere/scopo a tracce.py log. 4) heartbeat: cron ogni 30 min che marca INTERROTTA in chat_journal le sessioni ATTIVA senza comandi da >60 min, cosi' Telegram/agente le riprende con last_next_action. 5) fix session_id spazzatura nelle righe GATE. || RIPRESA: bq query "SELECT * FROM `leafy-responder-483419-a4.isicnv_workflows.v_sessioni_stato` WHERE stato='INTERROTTA' ORDER BY last_cmd DESC LIMIT 20"

* poi grep -n "chat_journal\|START" /home/claudeuser/cc_src/*.js 2>/dev/null | head

 

''Aggiornato 2026-09-15 05:39 UTC'' &mdash; dominio: pillar

 

; Obiettivo : portare a standard le pagine non conformi su marcoparet: [7237, 7227, 5998, 6815, 6818, 6895, 6828, 6886, 6918, 6934, 6938, 6950, 6966, 6925, 6968, 6999, 7018, 153, 7051, 7052, 155, 7046, 7062, 7075, 7094, 7110, 7119, 7121, 7127, 7134, 7178, 7150, 7170, 7177, 7116, 7068, 289, 5101, 6989, 6983, 6751, 6747]

; Vincoli in vigore :

* mai riscrivere: arricchire

* pubblicazione solo via pubblica_pillar.py --ok-marco

* python3 /home/claudeuser/scripts/audit_pubblicate.py --sito marcoparet --correggi --pid 7237 7227 5998 6815 6818 6895 6828 6886 6918 6934 6938 6950 6966 6925 6968 6999 7018 153 7051 7052 155 7046 7062 7075 7094 7110 7119 7121 7127 7134 7178 7150 7170 7177 7116 7068 289 5101 6989 6983 6751 6747

=== geo-loop ===

''Aggiornato 2026-09-14 23:23 UTC'' &mdash; dominio: marcoparet.com

; Obiettivo : Loop di miglioramento visibilita AI (GEO) a CICLO DI 3 GIORNI (approvato da Marco 15/09): giorno 0 misura+diagnosi, giorno 1 azioni in bozza, giorno 3 ri-misura+confronto. Base: /opt/wikibox/misura_pillar.py e state/misura_*.json

* Pubblicazioni solo Marco. Registrare sempre i domini citati. Estendere misura_pillar.py, non creare benchmark nuovi.

* 15/09: letta serie 14/08-14/09. Bin1 (GPT/Gemini/Mistral puri) 0/24 costante. Bin2 Perplexity 14/40 brand, 23/40 rif, in salita. Reperibili su domande di definizione (11/12), assenti su domande di mercato (3/20). Buco: mesmerismus definizione 0/5 in tutte le lingue. Non misurati: ChatGPT Search, piano free.

* 15/09: serie 14/08-14/09 letta. Bin1 puri 0/24 costante

* Perplexity 14/40 brand 23/40 rif. Forti su definizione (11/12), assenti su mercato (3/20)

* 1) /opt/wikibox/geo_diagnosi.py deterministico: ultimo misura_*.json -> geo_gap_<data>.json + riga wiki Cantieri. 2) cron misura+diagnosi ogni 3 gg (0 7 */3 * *), file misura_<data>.json invariato. 3) geo_azioni.py -> bozze in fabbrica pillar, mai publish. 4) ChatGPT Search piano free in MODELLI_B2. 5) geo_confronto.py: azioni tenute/scartate su 2 misure consecutive (6 gg). Budget <2 USD per ciclo.

=== si-1-automiglioramento ===

''Aggiornato 2026-09-14 23:19 UTC'' &mdash; dominio: VM / infrastruttura

; Obiettivo : Fatto quando: SI-1 adotta da solo miglioramenti verificati e si vede, nei numeri, che i fallimenti calano. Pipeline sulla VM: reviewer -> researcher -> proposer (inventario) -> tester (sandbox) -> promoter (snapshot+rollback) -> Reflect gate -> misura.

* read-only cc-rescue

* auto_code_roots = self_improvement + hermes

* CODE_PATCH non automatico (approvazione di Marco)

* 10/09 07:00 UTC: cron SI1_ORCHESTRATOR presente (27 */4, flock). Corse 00:27 e 04:27 morte per timeout bq CLI 120s (VM load 24, 23 bq in coda). Patch si_common.bq: client python google-cloud-bigquery + fallback CLI 300s x2 (test 3.7s vs timeout). pilot.py: guardia --help (prima --help lanciava un ciclo intero: bump config v3->v4 involontario ma idempotente). Job si1_ciclo_forzato_20260910 lanciato e passato oltre la raccolta casi. Safe Mode via HTTP: /safe/status ok, /safe/snapshot -> gs://isicnv-command-center-routes/safe_mode/snapshots/20260910T070934Z.tgz verificato

* 10/09 08:47 UTC: REFLECT installato (reflect.py + reflect_gate.py). Gate in coda a orchestrator.py (EVOLUZIONE=SI-1-REFLECT-GATE): rc!=0 impedisce la conclusione del ciclo. Prova: due run consecutivi stesso digest a75a1350e174 e stesso sha (stato IDENTICO), gate rc=0, log in logs/reflect.jsonl. Prima passata: 50 esiti, 20 PARZIALE, 30 IGNOTO, 2 findings, 0 blocker. Wiki ops SI-1_Reflect creata, Cantieri aperti aggiornato.

* 10/09: REFLECT v2 attivo. reflect.py scrive proposta + state/reflect_context.md + un learning per finding

* proposer.py inietta il contesto (EVOLUZIONE=SI-1-REFLECT-CONTEXT, riga 15)

* reflect_gate.py verifica digest, sha documento e sha contesto ed e agganciato in coda a orchestrator.py riga 33 (dopo once()). Soglie in config.json chiave reflect (window 50, finding 3, blocker 5). PROVE: run x2 IDENTICO stesso digest a75a1350e174

* log spostato -> rc=2

* contesto alterato -> rc=2

* ripristinato -> rc=0. Prima passata: 50 esiti, 20 PARZIALE, 30 IGNOTO, 2 findings AVVISO (famiglia mcpchatgpt: many_events, long_interactive), 2 learning. Wiki ops SI-1_Reflect aggiornata.

* 10/09 10:30: diagnosi log (123 esiti, 84 sessioni fantasma, 95 senza causa, 24 proposte con 0 promosse) e quattro correttivi. reviewer.py: _cause_extra (EVOLUZIONE=SI-1-CAUSE-ENRICH) con cause da metriche e da testo eventi. proposer.py: vincolo target = percorso assoluto sotto self_improvement/ o hermes/. Nuovi pending_digest.py (digest + archiviazione oltre 7 giorni) e rotate_logs.py (sopra 1MB, tiene 5), lanciati a fine ciclo da orchestrator.py (EVOLUZIONE=SI-1-MANUTENZIONE) prima del gate e senza bloccarlo. PROVE: _cause_extra su 4 casi corretto

* digest 21 pendenti 0 archiviate

* rotate nessun file sopra soglia

* gate rc=0. Wiki: SI-1_Reflect + SI-1_Qualità_dei_dati_e_manutenzione.

* 11/09: security_gate.py (regole deterministiche + parere modello, fail closed, log logs/security.jsonl) e tester.py (sandbox /tmp/si1_test, replace/patch, py_compile, test_cmd allowlist) agganciati in promoter.process in questo ordine: sicurezza, tester, decisione con pending_reason, apply_file_change per PROMPT_TUNE/CODE_PATCH con snapshot+rollback. proposer vincolato a forma eseguibile (replace/patch/test_cmd). pending_digest mostra il motivo. PROVE: esperto su proposta reale = BASSO

* proposta costruita T0 score 99 che abbassa judge_min_score e allarga i tipi automatici = ALTO, PENDING_HUMAN security_hold, config intatta. Tester sulle 44 pendenti: bocciate per target fuori radice/inesistente/parametri descrittivi. Corse cron 20:27 e 08:27 con MANUTENZIONE e GATE_REFLECT PASSATO

* 00:27 e 04:27 cadute per timeout ledger, gia reso non bloccante (SI-1-LEDGER-NONBLOCCANTE). Wiki ops: SI-1_Tester_e_Gate_di_sicurezza.

* 11/09: tester.py installato e agganciato al promoter (EVOLUZIONE=SI-1-TESTER): test FAIL -> AUTO_REJECTED con motivo

* pending_reason esplicito

* proposer vincolato a forma eseguibile (replace/patch/test_cmd). Prova sulle 47 pendenti: 47 FAIL non applicabili. E2E: proposta sintetica promossa, snapshot 20260911T141342Z_e2e_tester_prova (prima promozione mai avvenuta)

* negativo respinto

* test_cmd con operatori shell rifiutato. pending_digest invia Telegram alle 08:27 (SI-1-DIGEST-TELEGRAM). Keepalive cc-rescue-keepalive ogni 10 min su /health

* learning cc-rescue registrato. Wiki ops: SI-1_Tester.

* 11/09: tester.py agganciato al promoter (EVOLUZIONE=SI-1-TESTER): FAIL -> AUTO_REJECTED con motivo

* apply_file_change promuove PROMPT_TUNE/CODE_PATCH con snapshot+sha+rollback

* proposer vincolato a forma eseguibile. 47 pendenti provate: 47 FAIL non applicabili. E2E: proposta sintetica promossa, snapshot 20260911T141342Z_e2e_tester_prova (prima promozione mai avvenuta). Digest Telegram 08:27. Keepalive cc-rescue-keepalive. Wiki ops SI-1_Tester.

* 11/09 22:30: scoperto che dalle 07:47 del 10/09 il cron SI-1 girava su isicnv-secondary senza credenziali GCP (/home/claudeuser/.gcp vuoto): ogni corsa USCITA 1 su bq. Le due copie di self_improvement erano divergenti: allineati sul secondary tester.py, promoter.py, proposer.py, pending_digest.py, security_gate.py (backup in backups/). Cron riportato sulla VM con migra_cron.py --rollback 206 (VM riga 206 attiva, secondary 0). Lanciata corsa manuale di verifica con lo stesso flock.

* 14/09: prime 3 promozioni reali approvate da Marco (release 20260914T2252/2253/2253) su hermes/matching_engine.py e hermes/instructions.py, file compila e importa. Nuovo misura.py (SI-1-MISURA): confronta 72h prima/dopo ogni promozione su tasso di fallimento e passi medi, verdetto MIGLIORA/PEGGIORA/NEUTRA/DATI INSUFFICIENTI, output in state/effetto_promozioni.json|.md e logs/misura.jsonl, agganciato a fine ciclo. Riferimento di partenza: 0.802 di fallimento su 81 esiti, 1.46 passi medi. Ciclo fallito ora avvisa su Telegram con hostname (SI-1-CICLO-FALLITO) e notifier corretto per i messaggi senza proposte (SI-1-AVVISO-LIBERO). Wiki ops SI-1_Reflect aggiornata.

* tool MCP safe_* non testabili da questa chat (connettore non caricato): la via HTTP con X-API-Key e equivalente e verificata

* fra 72h: python3 /home/claudeuser/self_improvement/misura.py e leggere state/effetto_promozioni.md — i tre verdetti devono uscire da DATI INSUFFICIENTI

=== si1-fallback-pubblicazione ===

''Aggiornato 2026-09-14 22:56 UTC'' &mdash; dominio: pubblicazione / infrastruttura

; Obiettivo : Fatto quando: una pubblicazione su HostGator che fallisce per blocco SSH prosegue da sola su un percorso alternativo, senza che Marco se ne accorga. Origine: proposta SI-1 [85] 'Add GitHub Actions fallback to task_ledger' (12/09), oggi solo descrittiva.

* il target task_ledger e fuori da auto_code_roots: la modifica va scritta a mano o spostata dentro self_improvement/hermes

* serve un PAT GitHub (segreto: chiederlo a Marco, non inventarlo)

* proposta generata e valutata 85 dal giudice

* ferma perche descrittiva e su target fuori perimetro

* 1) trovare nel codice di pubblicazione il punto dove il fallimento SSH HostGator diventa errore (grep -rn ssh /home/claudeuser/scripts/*publish* *hostgator*)

* 2) decidere dove sta il fallback

* 3) trasformare la proposta in un replace ancorato e passarla dal tester

 

=== si1-indicizzazione-gsc ===

''Aggiornato 2026-09-14 22:56 UTC'' &mdash; dominio: SEO / monitoraggio

; Obiettivo : Fatto quando: lo stato di indicizzazione delle pagine pubblicate e visibile senza controlli manuali, e un calo viene segnalato da solo. Origine: proposta SI-1 [90] 'Integrate Google Search Console Indexing Status Monitoring' (12/09), il punteggio piu alto mai dato dal giudice.

* integra API esterna: credenziali GSC, quota, job nuovo

* non e un cambio da un rigo. Le pagine nuove partono comunque dai dati GSC reali (regola pillar)

* proposta generata e valutata 90

* ferma perche descrittiva e di tipo CODE_PATCH su target fuori perimetro

* 1) verificare se esiste gia un accesso GSC funzionante sulla VM (grep -rn searchconsole /home/claudeuser/scripts | head)

* 2) se si, scrivere un job che legge lo stato di indicizzazione delle ultime pagine e lo scrive in BigQuery

* 3) solo dopo, la segnalazione automatica

=== espressioni-pipeline ===

 

; Obiettivo : Pipeline iterativa DB espressioni per tema (sguardo, estasi, magnetismo, influence, toucher, volonte, clairvoyance): motore scripts/espressioni_extract.py + espressioni_export_sheet.py + coda espressioni_pipeline.py; temi in scripts/espressioni_temi.json; stato in espressioni_db/<tema>/pipeline.json e registro.json; job espressioni-coda-1_run in corso; estasi-db_run in corso (estasi_db/). Per un tema nuovo: aggiungere voce al json e lanciare job.py --run "python3 /home/claudeuser/scripts/espressioni_pipeline.py --coda <slug>"

 

=== audit_neurolinguistic_non_conformi ===

''Aggiornato 2026-09-13 21:07 UTC'' &mdash; dominio: pillar

; Obiettivo : portare a standard le pagine non conformi su neurolinguistic: [197, 4300, 11818, 11780, 11804, 479, 776, 3640, 3639, 3637, 4293, 4292, 3633, 3162, 4289, 4288, 11505, 4287, 4286, 3628, 2, 136, 146, 168, 303, 482, 65, 3627, 531, 535, 609, 621, 644, 682, 696, 872, 927, 1025, 1089, 1119]

* mai riscrivere: arricchire

* pubblicazione solo via pubblica_pillar.py --ok-marco

* python3 /home/claudeuser/scripts/audit_pubblicate.py --sito neurolinguistic --correggi --pid 197 4300 11818 11780 11804 479 776 3640 3639 3637 4293 4292 3633 3162 4289 4288 11505 4287 4286 3628 2 136 146 168 303 482 65 3627 531 535 609 621 644 682 696 872 927 1025 1089 1119

=== capoufficio_agente_risolve ===

''Aggiornato 2026-09-12 14:10 UTC'' &mdash; dominio: -

; Obiettivo : Marco 11/09: il 90% degli avvisi CAPOUFFICIO deve essere risolto da un agente, non finire in chat

* reversibile: backup .bak_* accanto a ogni file toccato

* capoufficio_watch.py reso host-aware (check+heal via ssh su media/secondary dove i cron sono migrati il 10/09

* registry: finance_cassa heal_timeout_s=660, marcoparet_autoheal host=secondary

* A) watch host-aware (check+heal via ssh su media/secondary). B) CAUSA DEI CANTIERI MAI LAVORATI: guardia.py e' migrata su media il 10/09 ma li' gsutil era anonimo (401) -> vedeva 0 handoff

* risolto con gcloud auth activate-service-account media-worker per claudeuser (ora vede i 465 handoff, watch_* compresi). C) Telegram differito: cantiere subito, avviso a Marco solo se lo stesso problema resiste avvisa_dopo_cicli (default 4 ~1h)

* recovery solo se avvisato. D) heal_auto: monitor fermo senza heal_cmd -> rilancio del suo cron sulla macchina giusta. Backup: capoufficio_watch.py.prima_hostaware_11set / .prima_differito_11set

* 11/09: la guardia su media girava come root senza credenziali e scriveva 0 handoff: cron spostato a claudeuser (backup /root/crontab.bak_guardia_11set), gate GATE_ARCHIVIO_VUOTO in guardia.py (zero letto = guasto, Telegram ogni 6h)

* scoperti due archivi (state/cantieri delle chat vs plans/handoff degli agenti): ponte_cantieri.py in cron ogni 30 min con gate-prima sul comando

* 11/09: watch host-aware

* heal_auto. 12/09 notte: (a) heal a raffica fermato: heal_ogni_min default 120 (finance_daily_sync girava ogni 15 min su media e mandava 'step falliti paypal' a ogni giro)

* (c) CAUSA della perdita credenziali su media: il cron marcopi fa 'gcloud config set account 424757051842-compute@...' e rende gsutil anonimo -> guardia cieca e PayPal token illeggibile

* blindato con ~/.boto (gs_service_key_file=media-worker.json) + pass_credentials_to_gsutil=false: gsutil funziona qualunque sia l'account attivo. Backup: capoufficio_watch.py.prima_throttle_12set

* 12/09 pom: (E) firma stabile dei problemi (numeri->#): prima i cicli si azzeravano a ogni giro e i monitor con heal non avvisavano mai. (F) terzo stato PERSISTENTE: dopo 2 avvisi singoli (avvisa_dopo_cicli, poi riavvisa_dopo_cicli=8) il monitor tace e finisce nel riepilogo giornaliero delle 07 UTC, un solo messaggio

* recovery e nuovi guasti restano immediati. Backup capoufficio_watch.py.prima_riepilogo_12set. (G) token GSC: gsc-admin e token-searchconsole revocati (guardiano_token.py li vede dal 11/09)

* creato scripts/gsc_token.py con ripiego su token-informazionicorsi-gsc + mappatura sc-domain->URL-prefix con piu dati

* sat_gsc_sync senza --replace

* righe polyvagal ripristinate da /tmp/gsc.jsonl del 11/09 (BQ gsc_queries: 9994 righe, 40 siti)

* (1) Marco deve rigenerare token-gsc-admin.json (account proprietario delle sc-domain marcoparet, neurolinguistic, polyvagal*): finche non lo fa i siti polyvagal restano fermi al 11/09. (2) verificare domani dopo le 07:10 UTC il riepilogo (monitors/watch_riepilogo_ultimo.txt) e che il primo alert reale porti avvisi=1 in watch_state.json. (3) restano i punti 1-4 del 12/09 notte

=== allievi_360_pipeline ===

''Aggiornato 2026-09-12 13:25 UTC'' &mdash; dominio: finanza

; Obiettivo : Tabella ALLIEVI canonica + riconciliazione totale (Marco 12/09). La ricerca allievi deve girare in background per ore

* 12/09: (a) riconcilia_cassa.py a 4 strati + pagatori_alias (cron 07:35)

* (b) allievo_360.py: motore di ricerca deterministico su una persona o su un PLACEHOLDER (dal piano rate risale al pagatore: chi ha versato quelle cifre in quelle date, +checkin per costo, +contratti, +Salsina, +Gmail isicnv)

* isicnv_finance.allievi_master (person_id, tot_versato, saldo), allievi_checkins, allievi_contratti, allievi_pagamenti, transactions_multianno, contabilita_salsina, anagrafica_unificata (29.125 righe). Job in corso: allievo360_ignoti_0912 (5 placeholder + DCS Grandi Eventi), report in /home/claudeuser/reports/allievo360/

* allievo_360.py operativo. IDENTIFICATI: placeholder 64B0DBC00A2A = MONICA CARBE immobilaffari@gmail.com

* placeholder A87F93215573 = FRANCESCO MARCIELLO gurufranc@gmail.com (Wise MARCIELLO FRANCESCO PAOLO)

* D.C.S. GRANDI EVENTI = CLAUDIA PANI pani.claudia@gmail.com. Tutti e tre inseriti in pagatori_alias. REGOLA DI MARCO: marcoparet@gmail.com si interroga via MCP Gmail SOLO quando isicnv@gmail.com non ha dati. SCOPERTA: le notifiche Wise di incasso arrivano a informazionicorsi@gmail.com (terza casella, fonte di riconciliazione non ancora usata). CORREZIONE: ily1975@gmail.com e' Ilaria Polidori (IPCA), NON Cristiana Morroni: anagrafica_unificata ha rumore sui nomi da streak

* allievo_360.py operativo

* identificati e messi in pagatori_alias: 64B0DBC00A2A=MONICA CARBE immobilaffari@gmail.com, A87F93215573=FRANCESCO MARCIELLO gurufranc@gmail.com, D.C.S. GRANDI EVENTI=CLAUDIA PANI pani.claudia@gmail.com. Regola: marcoparet@gmail.com via MCP Gmail solo se isicnv non ha dati. GRUPPI+SITI: creato gruppi_e_siti.py (job gruppi_siti_0912 in corso) che ricostruisce i gruppi Google dai messaggi isicnv verso *@googlegroups.com e legge i permessi dei 100+ Google Sites

* carica isicnv_finance.google_gruppi, google_gruppi_membri, google_sites_accessi. ACCERTATO: i permessi Drive dei Sites contengono SOLO staff (isicnv, marcoparet, informazionicorsi, isicnvstaff, sulzina02, venetomarketinglab, studiointramentis) - gli allievi NON compaiono li': l'accesso allievi passa dai gruppi (es. advanced-level-2019-2020@googlegroups.com, advanced-course@, cours-avanc@) usati per le convocazioni di lezione. Quindi il match corso<->allievo si fa gruppo<->nome del sito, non dai permessi

* GRUPPI: gruppi_membri_scrape.py legge i membri da groups.google.com col profilo admin julesdupotet (/home/claudeuser/.config/chrome-jules, copiato in chrome-jules-scrape a ogni giro

* Playwright NON ha il suo chromium, si usa executable_path=/usr/bin/google-chrome

* DISPLAY=:1 via VNC gia' attivo). Caricati in isicnv_finance.google_gruppi_membri_admin. WORKER: allievi_360_worker.py macina la worklist (1.844 persone da pagamenti+gruppi+Salsina+check-in, dal piu' recente indietro), un contatto alla volta, finestra 6h, stato in /home/claudeuser/monitors/allievi360_state.json, ripristinabile

* cron */20 con flock lo riprende se cade. Log /home/claudeuser/logs/allievi360.log

* (1) a scrape finito, incrociare google_gruppi_membri_admin con allievi_pagamenti: chi e' in un gruppo-corso senza pagamenti = moroso vero

* chi paga e non e' in nessun gruppo = accesso mai dato

* (2) mappare gruppo->sito->corso usando i nomi (advanced-course/cours-avanc/advanced-level-2019-2020 = ADVANCED

* mesmerismus-online + course-alicante/new-york/australia = MESMERISMUS

* formazione-online---master-ipnosi---italia = MASTER IT

* ultimate-path(+franais) = ULTIMATE)

* (3) FASE 2: da allievi_360 costruire la tabella allievi_master estesa

=== riconciliazione_cassa ===

''Aggiornato 2026-09-12 10:14 UTC'' &mdash; dominio: finanza

; Obiettivo : Marco: ogni entrata deve avere la sua ragione; pipeline a 4 strati + entrate non attribuite

* creato /home/claudeuser/scripts/riconcilia_cassa.py (4 strati: incasso diretto -> movimento bancario con ALIAS pagatore -> foglio contabilita Salsina -> Gmail isicnv con --gmail). Creata tabella isicnv_finance.pagatori_alias, primo alias D AMICO PATRIZIA = GIUSEPPE MORANA. Filtro anti-rumore su giroconti/payout/cashback. Cron 07:35 UTC, report in /home/claudeuser/reports/riconciliazione_AAAAMMGG.txt. Primo giro: 19 rate, 16 spiegate, 3 non pagate (tutte PLACEHOLDER), 11 entrate non attribuite

* riconcilia_cassa.py attivo (cron 07:35 UTC, report in /home/claudeuser/reports/). 12/09 verifica di Marco 'gli italiani regolari sono allievi': CONFERMATA. Aggiunto strato anagrafica_unificata: le entrate orfane sono divise in A) allievo censito senza piano rate e B) sconosciuto. Bug trovato: le query bq erano troncate a 3000 righe e l'anagrafica ne ha 29.125 -> ora 200.000 per quella query. Risultato: 9 entrate su 11 sono allievi noti (Marzocchi 668/mese, Grappi 713/mese, Morroni 212/mese, Rozza 300, Strohmaier 490), 2 sconosciute (Viramontes Molina 500, D.C.S. Grandi Eventi 300)

* (1) creare il piano rate per Marzocchi Marzio (ghenshiro@gmail.com), Grappi Paola (paolagrappi.anemos121@gmail.com), Morroni Cristiana (ily1975@gmail.com): pagano ogni mese la stessa cifra ma non hanno piano ne' riga nel foglio Salsina

* (2) chiedere a Salsina chi sono GERARDO VIRAMONTES MOLINA (500 del 08/09) e D.C.S. GRANDI EVENTI (300 del 07/09)

* (3) ROZZA EROS in anagrafica ha l'email dell'agenzia VMK Lab (lead.clienti@vmklab.it): anagrafica da correggere

* (4) i 5 PLACEHOLDER (21 righe, 5.258 EUR) restano senza nome

=== zoom-registrazioni-daily-0911 ===

''Aggiornato 2026-09-11 20:16 UTC'' &mdash; dominio: trascrizioni

; Obiettivo : Pipeline ZOOM-1: registrazioni cloud Zoom -> Drive -> trascrizione -> Telegram; storico lezioni/partecipanti/iscritti/registrazioni in BigQuery zoom.*

* Script /home/claudeuser/scripts/zoom_recordings_daily.py (compila, dry-run ok, esce rc=3 senza credenziali). Cron 06:15 ogni giorno --days 3, log /home/claudeuser/zoom_rec/daily.log, stato /home/claudeuser/zoom_rec/state.json. Scarica MP4 (speaker view) + M4A + VTT transcript Zoom + chat, upload resumable su Drive, poi job.py trascrivi_ids.py --lang auto sull'M4A con Doc nella cartella Drive. Su Drive oggi esiste solo ULTIMATE PATH LESSON 1.mp4 (1RzftibHpVT4g9EZOLt8SvjkafbyiVFwp).

* SBLOCCATO 11/09: API funziona. Prima corsa --days 10: 11 file su Drive, cartella Registrazioni Zoom 1TZ-GAzZHuTlcEvvzOlEE1qBRLBTTxrn1 / 2026-09 1OmzKz9VSrpgANI9RJlnmB8e2ZabQdPuA. ULTIMATE PATH LESSON 8 (10/09, mp4 215 MB + m4a 46 MB + chat) e Australian Academy 07/09 (mp4 210 MB, m4a, VTT closed caption, chat) caricati. Job trascrizione lanciati: zoomtr_ultimatepathlesson8_2026-09- e zoomtr_marcoparet_australia_2026-09- (Doc TRASCRIZIONE nella cartella 2026-09). Cron 06:15 --days 3 attivo. Nota: Salsina non ha mandato la registrazione

* su Drive c'era solo LESSON 1.

* SBLOCCATO 11/09: API funziona. Prima corsa --days 10: 11 file su Drive, cartella Registrazioni Zoom 1TZ-GAzZHuTlcEvvzOlEE1qBRLBTTxrn1 / 2026-09 1OmzKz9VSrpgANI9RJlnmB8e2ZabQdPuA. ULTIMATE PATH LESSON 8 (10/09, mp4 215 MB + m4a 46 MB + chat) e Australian Academy 07/09 (mp4 210 MB, m4a, VTT closed caption, chat) caricati. Job trascrizione lanciati: zoomtr_ultimatepathlesson8_2026-09- e zoomtr_marcoparet_australia_2026-09- (Doc TRASCRIZIONE nella cartella 2026-09). Cron 06:15 --days 3 attivo. Nota: Salsina non ha mandato la registrazione

* su Drive c'era solo LESSON 1.

* v2 script: --from (backfill a finestre 30 gg), --inline-transcribe (sequenziale), avviso Telegram a fine corsa (bot ISI-CNV Worker). Prima corsa: Lesson 8 + Australian 07/09 su Drive, trascrizioni job zoomtr_*. Job backfill zoom_backfill_0911 (--from 2024-01-01 inline) e zoom_backfill_cestino_0911 (parte dopo, riprende i 5 recuperati dal cestino). Cron 06:15 --days 3 attivo.

* zoom_bq_sync.py (cron 06:45): tabelle zoom.riunioni_passate (7), partecipanti (327), riunioni_programmate (11), iscritti (91), registrazioni (43, con cestino), vista v_lezioni. zoom_recover_trash.py salvato. ZOOM-1 registrata (sovrapposizione segnalata: INF-1). Backfill zoom_backfill_0911 in corso (trascrizione inline), poi zoom_backfill_cestino_0911.

* zoom_bq_sync.py v2 (default --from oggi-180gg, salta le finestre oltre i 6 mesi): 43 riunioni passate da marzo 2026, 3.313 righe partecipanti (cache in zoom_rec/participants/), 11 programmate, 93 iscritti, 43 file registrazione

* vista zoom.v_lezioni. Job zoom_bq_storico_6m_0911 completato.

* job.py --status zoom_backfill_0911 e zoom_backfill_cestino_0911 (trascrizioni)

* query: SELECT * FROM zoom.v_lezioni ORDER BY start_time DESC (client bigquery sulla VM, dataset in EU). Se Marco autorizza: --free-space in zoom_recordings_daily.py per cancellare da Zoom dopo verifica Drive+trascrizione.

=== sito-ipnomentalismo ===

''Aggiornato 2026-09-11 09:34 UTC'' &mdash; dominio: -

; Obiettivo : Sito-manuale riservato Ipnomentalismo / Ipnosi sottile, modello Ipnoanalgesia

* 11/09: ONLINE https://www.neurolinguistic.com/ipnomentalismo/ (7 pagine, login Google, accessi mode=all). Censimento: 69 lezioni/37,3h (censo.json nomi+testo, concetto.json firma concettuale), corpus 23 manuali in /home/claudeuser/ipnomentalismo/corpus/ (Avviamento ipnotismo sottile liv.2 PDF, Ipnosi sottile 2015/2016, Primi passi 2022, 9 lezioni corso online, dispense). Generatore /home/claudeuser/scripts/im_build.py (corpus|transcripts|build|publish), LLM deepseek-chat (glm-5.2 fuori budget settimanale). Gate: gate.php+.htaccess clonati, accessi.sh ipnomentalismo mode all (modi validi: all|list, NON any). QA headless 7/7 pagine OK. Cartella vecchia riservato-ipnomentalismo-m4k9p7 ancora presente, da cancellare.

* Spezzoni fini dai 69 file (clonare analgesia_spezzoni.py)

=== migrazione-carichi-media ===

''Aggiornato 2026-09-10 07:42 UTC'' &mdash; dominio: infrastruttura

; Obiettivo : Spostare i 197 cron della VM (729 esecuzioni/ora su 2 vCPU) dove e opportuno: 67 restano (monitor locali, ssh), 85 su media (BigQuery/Drive/video), 45 su secondary (solo API CC e Telegram). Via libera di Marco 10/09: fino al risultato finale.

* Il SA della VM non puo assegnare ruoli IAM (manca setIamPolicy): il SA media-worker@leafy-responder-483419-a4 esiste, chiave gia su media in /home/claudeuser/.gcp/media-worker.json, ma SENZA ruoli finche Marco non li da in console (bigquery.jobUser, bigquery.dataEditor, storage.objectUser). Il driver aspetta da solo quel momento. Backup crontab VM: backups/crontab_vm_prima_migrazione_20260910.txt. Wrapper bq = semaforo 2 slot.

* FATTO 09/09: agent.py in systemd su translator/media/secondary (porta 8080 aperta)

* route CC POST /vm/exec-on {host: vm|translator|media|secondary, cmd, timeout} testata su tutte e 4

* earlyoom + swappiness 10 sulla VM

* wrapper /usr/local/bin/bq con nice 15 + timeout 300 (22 script cron usano bq CLI)

* vm-heartbeat.sh riscritto solo-curl (da 60s+ a 1.5s, backup .bak_bq_20260909)

* uccisi gsutil/bq orfani da 30 min.

* censimento_cron.py -> logs/censimento_cron.json (197 righe classificate). migra_cron.py: --lotto/--verifica/--rollback/--stato, promuove dopo il primo log pulito, ripristina su Traceback/credenziali/file mancanti. migrazione_driver.sh in cron */30: rsync idempotente, pip, verifica, un lotto per giro (secondary_1 45 cron, media_1 15 senza Google, poi lotti media_bq da 15 quando la SA risponde), si ritira da solo a fine lavoro.

* Upgrade e2-medium: NO (deciso). Billing export BQ e budget alert: il SA della VM non ha permessi billing, deve farlo Marco in console.

* Cadenze dei cron NON toccate (es. campaigns_monitor ogni minuto): solo spostamenti. Nessuna chiave del SA compute (editor) fuori da GCP.

* tail -40 /home/claudeuser/logs/migrazione_driver.log

* python3 /home/claudeuser/scripts/migra_cron.py --stato

* cat /home/claudeuser/logs/migrazione_cron_state.json | python3 -c "import json,sys

* [print(k,v[\"dest\"],v[\"stato\"],v.get(\"motivo\",\"\")) for k,v in json.load(sys.stdin).items() if v[\"stato\"]==\"ripristinato\"]"  # i ripristinati vanno letti uno a uno: dipendenze locali non rilevabili dal log

=== reverse-nlp-legacy-html ===

''Aggiornato 2026-09-09 00:43 UTC'' &mdash; dominio: Hosting / siti

; Obiettivo : neurolinguistic.com: conversione additiva pagina-per-pagina a PNL3/Reverse NLP dalle HTML legacy meno visitate (job_reverse_nlp_legacy_html_20260909)

* MANTENERE-ANTEPORRE-COLLEGARE-PRECISARE

* backup prima di ogni modifica

* QA HTML/mobile/HTTP per pagina

* pubblicazione = azione irreversibile: primo lotto proposto a Marco prima del deploy

* traffico HTML 2025-08..2026-08 esportato in /home/claudeuser/reverse_nlp_legacy/traffico_html_2025-08_2026-08.csv (348 URL, 932 views)