Cantieri aperti: differenze tra le versioni

[versione verificata][versione verificata]
WikiBot (discussione | contributi)
handoff automatico
WikiBot (discussione | contributi)
handoff automatico
 
(9 versioni intermedie di uno stesso utente non sono mostrate)
Riga 7: Riga 7:


== Cantieri attivi ==
== Cantieri attivi ==
=== capoufficio_agente_risolve ===
''Aggiornato 2026-09-12 14:10 UTC'' — dominio: -
; Obiettivo : Marco 11/09: il 90% degli avvisi CAPOUFFICIO deve essere risolto da un agente, non finire in chat
; Vincoli in vigore :
* reversibile: backup .bak_* accanto a ogni file toccato
; Fatto (con prova) :
* capoufficio_watch.py reso host-aware (check+heal via ssh su media/secondary dove i cron sono migrati il 10/09
* backup .prima_hostaware_11set)
* registry: finance_cassa heal_timeout_s=660, marcoparet_autoheal host=secondary
* /var/log/isicnv creato su media e secondary
* 9 monitor in RECOVERY
* 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
* commessa.py chiudi rifiuta gli handoff in prosa senza job (GATE_HANDOFF_PARCHEGGIO, off con touch /home/claudeuser/sessions/GATE_HANDOFF_OFF)
* primo giro guardia in corso su 465 cantieri
* 11/09: watch host-aware
* guardia su media con credenziali
* Telegram differito (avvisa_dopo_cicli)
* 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)
* (b) log_clean su log mai scritto = OK (argo_watch.log e cassa_check.log non esistevano perche' /var/log/isicnv mancava fino al 11/09 13:37)
* (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
* gate_pagina_protetta e sat_gsc_sync adattati (bak_gsc_12set)
* sat_gsc_sync senza --replace
* righe polyvagal ripristinate da /tmp/gsc.jsonl del 11/09 (BQ gsc_queries: 9994 righe, 40 siti)
; Prossimo passo :
* (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'' — dominio: finanza
; Obiettivo : Tabella ALLIEVI canonica + riconciliazione totale (Marco 12/09). La ricerca allievi deve girare in background per ore
; Fatto (con prova) :
* 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)
* fonti gia' in BigQuery: isicnv_contacts.zoom_participants, streak_boxes_daily, contatti_master (con note_crm), emails_master, staff_inbox_raw
* 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
; Prossimo passo :
* (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
* (4) placeholder AC4B36231C82 a DeepSeek
=== 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
; Fatto (con prova) :
* 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)
; Prossimo passo :
* (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
=== chat-s20260911-si1secondary-qqnl4c ===
''Aggiornato 2026-09-12 00:00 UTC'' &mdash; dominio: chat_riprese
; Obiettivo : Completare il deploy SI-1: riparare il crash gcloud (credenziali rotte), installare in cron la copia dell'orchestrator su secondary e produrre la consegna verificabile D1
; Vincoli in vigore :
* gate=auto
* non chiedere a Marco
* verifica prima di dichiarare fatto
; Fatto (con prova) :
* chat S20260911-si1secondary-qqnl4c chiusa senza prova
* contesto ricostruito da riprendi_chat
; Prossimo passo :
* 1|Diagnosticare il crash gcloud riportato nel messaggio umano non letto ('Credentials' object has no attribute 'private_key_id')|gcloud info --run-diagnostics
* gcloud auth list
* gcloud config list
* 2|Ripristinare le credenziali gcloud (re-auth interattiva o service account)|SERVE MARCO: gcloud auth login (richiede browser/OTP)
* alternativa non interattiva: gcloud auth activate-service-account --key-file=<chiave> se disponibile sul sistema
* 3|Installare la copia dell'orchestrator SI-1 nel crontab di secondary, replicando la voce '27 */4' gia' attiva sulla VM|su secondary: crontab -e e aggiungere la riga '27 */4 <comando orchestrator SI-1>' identica a quella della VM
* 4|Verificare la schedulazione su entrambe le macchine e l'esecuzione dell'orchestrator|crontab -l su VM e su secondary (voce '27 */4' per SI-1 presente)
* controllare log/ultima esecuzione dell'orchestrator
* 5|Produrre la consegna verificabile D1 (output crontab -l di VM e secondary + log esecuzione) e chiudere la chat con prova di completamento|aggiornare il GIORNALE con END verificato e D1 consegnato al posto di 'D1 MANCA'
=== chat-s20260910-claudesi1ref-1kurya6 ===
''Aggiornato 2026-09-11 23:40 UTC'' &mdash; dominio: chat_riprese
; Obiettivo : Chiudere verificato il cantiere SI-1 Reflect (chat S20260910-claudesi1ref-1kurya6): eseguire le verifiche rimaste su si1.cron.log, definire la consegna verificabile D1, aggiornare wiki/handoff, e gestire il messaggio umano non letto sull'errore gcloud.
; Vincoli in vigore :
* gate=auto
* non chiedere a Marco
* verifica prima di dichiarare fatto
; Fatto (con prova) :
* chat S20260910-claudesi1ref-1kurya6 chiusa senza prova
* contesto ricostruito da riprendi_chat
; Prossimo passo :
* 1|Leggere e gestire il messaggio umano non letto: errore gcloud (AttributeError: 'Credentials' object has no attribute 'private_key_id')|gcloud info --run-diagnostics
* verificare/rigenerare le credenziali (gcloud auth login o activate-service-account) e riportare l'esito in chat
* 2|Eseguire la verifica rimasta dal journal 10:32|grep -E "MANUTENZIONE|GATE_REFLECT" /home/claudeuser/self_improvement/si1.cron.log
* 3|Eseguire le verifiche pendenti precedenti|tail -30 /home/claudeuser/self_improvement/si1.cron.log
* python3 /home/claudeuser/self_improvement/reflect_gate.py --auto
* 4|Definire e verificare il deliverable D1 'consegna verificabile' (es. digest gate rc=0 + righe GATE_REFLECT nel log) e documentarlo|confrontare digest a75a1350e174 e rc del gate
* registrare D1 nel journal
* 5|Aggiornare wiki SI-1_Reflect e Cantieri aperti con l'esito verificato e chiudere il cantiere ripresa_S20260910-claudesi1ref-1kurya6|modifica wiki + entry GIORNALE END verificato
* 6|SERVE MARCO: sbloccare il gate umano del cantiere ripresa_S20260910-claudesi1ref-1kurya6 (campanello: esame immediato) se la verifica automatica non basta a chiudere
=== chat-s20260911-clauderegist-sskkcz ===
''Aggiornato 2026-09-11 23:00 UTC'' &mdash; dominio: chat_riprese
; Obiettivo : Completare e verificare la pipeline Zoom zoom_recordings_daily.py: chiudere i 2 job backfill in corso, assicurare che le 5 registrazioni recuperate (inclusa Lesson 8, presente solo su cloud Zoom) siano su Drive, definire il deliverable D1 mancante, e risolvere il crash gcloud segnalato nei messaggi umani non letti
; Vincoli in vigore :
* gate=auto
* non chiedere a Marco
* verifica prima di dichiarare fatto
; Fatto (con prova) :
* chat S20260911-clauderegist-sskkcz chiusa senza prova
* contesto ricostruito da riprendi_chat
; Prossimo passo :
* 1|Riprendere il contesto completo della sessione|python3 /home/claudeuser/scripts/handoff.py --resume zoom-registrazioni-daily-0911
* 2|Verificare se i 2 job backfill avviati alle 18:35 sono terminati con successo|ps aux | grep -iE 'zoom|backfill'
* controllare log/output di zoom_recordings_daily.py e del cron installato
* 3|Diagnosticare il crash gcloud non letto ('Credentials' object has no attribute 'private_key_id')|gcloud info --run-diagnostics
* gcloud components update
* ispezionare ~/.config/gcloud/application_default_credentials.json e ~/.config/gcloud/credentials.db
* 4|Riparare le credenziali gcloud (ricreare ADC o riattivare service account con key-file valida)|gcloud auth activate-service-account --key-file=<percorso chiave.json> oppure rm ~/.config/gcloud/application_default_credentials.json e rieseguire gcloud auth application-default login
* 5|Verificare che le 5 registrazioni recuperate dal cestino Zoom siano scaricate e caricate su Drive, inclusa Lesson 8 (attualmente solo su cloud Zoom)|ls -la sulla cartella di destinazione delle registrazioni
* verifica presenza di Lesson 8 su Google Drive
* 6|Definire e produrre il deliverable D1 (consegna verificabile) esplicitamente mancante|precisare la consegna verificabile dalla chat (es. report pipeline + elenco file caricati su Drive) e validarla
* 7|SERVE MARCO: credenziali Zoom S2S (blocco citato nel STEP delle 17:16) e, se la riparazione gcloud richiede login browser/OTP, completare gcloud auth login con Marco|
=== si-1-automiglioramento ===
=== si-1-automiglioramento ===
''Aggiornato 2026-09-11 22:28 UTC'' &mdash; dominio: VM / infrastruttura
''Aggiornato 2026-09-11 22:28 UTC'' &mdash; dominio: VM / infrastruttura
Riga 51: Riga 196:
* grep -nE "test:|AUTO_PROMOTED|pending_reason|Traceback|GATE_REFLECT" /home/claudeuser/self_improvement/si1.cron.log | tail -15 : verificare la corsa manuale e la 00:27
* grep -nE "test:|AUTO_PROMOTED|pending_reason|Traceback|GATE_REFLECT" /home/claudeuser/self_improvement/si1.cron.log | tail -15 : verificare la corsa manuale e la 00:27
* poi cantiere proposer-con-contenuto-del-target
* poi cantiere proposer-con-contenuto-del-target
=== capoufficio_agente_risolve ===
''Aggiornato 2026-09-11 22:09 UTC'' &mdash; dominio: capoufficio
; Obiettivo : Marco 11/09: il 90% degli avvisi CAPOUFFICIO deve essere risolto da un agente, non finire in chat
; Vincoli in vigore :
* reversibile: backup .bak_* accanto a ogni file toccato
; Fatto (con prova) :
* capoufficio_watch.py reso host-aware (check+heal via ssh su media/secondary dove i cron sono migrati il 10/09
* backup .prima_hostaware_11set)
* registry: finance_cassa heal_timeout_s=660, marcoparet_autoheal host=secondary
* /var/log/isicnv creato su media e secondary
* 9 monitor in RECOVERY
* 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
* commessa.py chiudi rifiuta gli handoff in prosa senza job (GATE_HANDOFF_PARCHEGGIO, off con touch /home/claudeuser/sessions/GATE_HANDOFF_OFF)
* primo giro guardia in corso su 465 cantieri
* 11/09: watch host-aware
* guardia su media con credenziali
* Telegram differito (avvisa_dopo_cicli)
* 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)
* (b) log_clean su log mai scritto = OK (argo_watch.log e cassa_check.log non esistevano perche' /var/log/isicnv mancava fino al 11/09 13:37)
* (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
; Prossimo passo :
* (1) verificare che finance_daily_sync delle 06:04 UTC su media passi lo step paypal (log media /home/claudeuser/logs/finance_daily.log)
* (2) guardia.log su media: dal giro 18:36 avanzati 384 handoff, ma i cantieri watch_* hanno solo --verifica, non riparano: valutare se il cantiere debba portare il heal_cmd come comando
* (3) i messaggi 'FINALIZZATORE R109 job DONE' in Telegram sono un'altra sorgente di rumore (job.py), chiedere a Marco se vuole solo i FAILED
* (4) dopo 24h contare in ops_log risolti in silenzio vs ALERT


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