Cantieri aperti: differenze tra le versioni

[versione verificata][versione verificata]
WikiBot (discussione | contributi)
handoff automatico
WikiBot (discussione | contributi)
handoff automatico
 
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 ===
=== allievi_360_pipeline ===
''Aggiornato 2026-09-12 13:25 UTC'' — dominio: finanza
''Aggiornato 2026-09-12 13:25 UTC'' — dominio: finanza
Riga 161: 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'' — 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 ===