Wiki Progetto di Ricerca Metodo Paret

Cantieri aperti: differenze tra le versioni

[versione verificata][versione verificata]
← Differenza precedenteDifferenza successiva →
VisualeWikitesto
WikiBot (discussione | contributi)
Ricercatori, Bot, Burocrati, Amministratori
5 927 modifiche
handoff automatico
WikiBot (discussione | contributi)
Ricercatori, Bot, Burocrati, Amministratori
5 927 modifiche
handoff automatico
Riga 7: Riga 7:


== Cantieri attivi ==
== Cantieri attivi ==
=== gate-mcp-log-chat ===
''Aggiornato 2026-09-23 15:05 UTC'' — dominio: ingegnere
; Obiettivo : OGNI chat che tocca il sistema (Claude, ChatGPT, Gemini; MCP o VM; nuova o gia' in corso) dichiara OBIETTIVO FINALE (che cosa e' stato chiesto) e OBIETTIVO PARZIALE (che cosa sta facendo adesso) e lascia un log completo in BigQuery: sessione con scopo, ogni chiamata tool con session_id, STEP con parziale, chiusura R152. Fatto quando: (a) chat MCP-only senza sessione -> rifiuto dal bridge su ogni tool; (b) chat con sessione ma senza obiettivo -> blocco al primo comando con richiesta di dichiararlo (anche le chat vecchie: 'registrazione tardiva'); (c) query BQ mostra tutte le chat di una giornata con obiettivo finale, ultimo parziale e stato; la Guardia segnala su Telegram le anomalie e Marco puo' vedere/coordinare gli obiettivi in corso.
; Vincoli in vigore :
* Additivo: EMERGENZA-* libero
* cc_session_open unico tool senza sessione
* R102 invariato. Bridge = Cloud Run sheets-connector. gate.sh: backup .bak prima di toccarlo
* test con sessione finta prima di attivare. Nessuna cancellazione di log. Coordinare con R90 (commessa = obiettivo finale), R94/R95, R145, R152, R153. Deploy bridge in produzione: OK esplicito di Marco al momento.
; Fatto (con prova) :
* 23/09/2026: MRO v8.0 STEP 0 + R153 (registrazione al gate come prima azione) scritti
* rule nel grafo rule_1790175473222_2pk2ae
* wiki ops rules.md/log.md aggiornati. Marco ha approvato il piano a 3 livelli (msg R102 16d16f0d8ec6cdc54590b0ccd6b1d846fa9d989e).
* 23/09/2026: MRO v8.0 STEP 0 + R153
* rule grafo rule_1790175473222_2pk2ae
* wiki ops aggiornata. MISURATO sul giornale (7gg, isicnv_workflows.chat_sessions_log): 114 sessioni, 92 con START, 30 con STEP, 9 con END, 37 END_NONVERIFICATO
* nessuna auto/emergenza. Cioe': chi usa la VM viene registrato (R95 funziona), ma 4 chat su 5 non lasciano STEP e quasi nessuna chiude
* le chat MCP-only non compaiono affatto. Esiste gia' il campo scopo (session/open?scopo, file sessions/SID.scopo, commessa R90 auto al primo comando se c'e' scopo): e' la base per l'obiettivo finale. Manca l'obiettivo PARZIALE. Marco 23/09 (msg 16d16f0d + due vocali): 'la cosa piu' semplice e' che una chat dica il suo obiettivo: cosi' abbiamo il log, vediamo se e' conforme, possiamo coordinare piu' obiettivi
* e poi l'obiettivo parziale della situazione, questo e' sicuro'.
; Provato ed escluso :
* Affidarsi alla sola disciplina della chat (e' il buco attuale: le chat MCP-only sfuggono).
* Affidarsi alla sola disciplina della chat. Considerare 'registrate' le chat vecchie solo perche' passano dal gate VM: senza obiettivo dichiarato il log non dice che cosa fanno.
; Prossimo passo :
* LIVELLO 0 (subito, VM, piccolo): gate.sh - se la sessione non ha sessions/SID.scopo, il primo comando viene bloccato (rc 97, stile R102) con: 'dichiara OBIETTIVO FINALE e OBIETTIVO PARZIALE: python3 scripts/chat_journal.py --session SID --tipo OBIETTIVO --finale ... --parziale ...'
* vale anche per le sessioni gia' aperte (registrazione tardiva). chat_journal.py: nuovo tipo OBIETTIVO (scrive .scopo + riga BQ) e STEP con --parziale obbligatorio. Vista BQ v_chat_obiettivi: per sessione obiettivo finale, ultimo parziale, ultimo evento, stato. LIVELLO 1: bridge MCP - middleware session obbligatoria su tutti i tool tranne cc_session_open
* cc_session_open richiede scopo (obiettivo finale)
* log di ogni chiamata in isicnv_workflows.mcp_tool_log. LIVELLO 2: parola d'ordine giornaliera nel MRO richiesta da cc_session_open. LIVELLO 3: Guardia incrocia giornale+mcp_tool_log+gate_activity -> Telegram
* report giornaliero a Marco 'chat di oggi: obiettivo, parziale, stato' (base per coordinare obiettivi e verificarne la conformita').
=== si-1-automiglioramento ===
=== si-1-automiglioramento ===
''Aggiornato 2026-09-23 14:01 UTC'' — dominio: VM / infrastruttura
''Aggiornato 2026-09-23 16:13 UTC'' — dominio: VM / infrastruttura


; Obiettivo : Fatto quando: SI-1 adotta da solo miglioramenti verificati, annulla da solo quelli che peggiorano, allarga la propria autonomia sui numeri, e Hermes Daily alimenta SI-1 con idee lette e SI-1 alimenta Hermes con i ricorrenti misurati.
; Obiettivo : Fatto quando: un solo ciclo (SI-1) decide, prova, applica e misura i miglioramenti da tutte le sorgenti (chat, Hermes), e un solo digest (Hermes Daily) li racconta. Marco 23/09: collegare tutto o concentrare.
; Vincoli in vigore :
; Vincoli in vigore :
* read-only cc-rescue
* read-only cc-rescue
* auto_code_roots = self_improvement + hermes
* auto_code_roots = self_improvement + hermes
* soglia giudice governata da autonomia.py
* soglia governata da autonomia.py
* backup e marcatore EVOLUZIONE su ogni modifica
* backup e marcatore EVOLUZIONE su ogni modifica
* gate=auto
* non chiedere a Marco
* verifica prima di dichiarare fatto
; Fatto (con prova) :
; Fatto (con prova) :
* 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 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
Riga 97: Riga 65:
* HERMES-SEVERITY-NUM, prova True). Ponte Reflect->system_events friction (SI-1-REFLECT-FRICTION, idempotente). Proposte Hermes: 0/54 mai decise -> 12 chiuse GIA_RISOLTO/GIA_COPERTO con motivo, restano 42. Wiki SI-1_Reflect sez. 10.
* HERMES-SEVERITY-NUM, prova True). Ponte Reflect->system_events friction (SI-1-REFLECT-FRICTION, idempotente). Proposte Hermes: 0/54 mai decise -> 12 chiuse GIA_RISOLTO/GIA_COPERTO con motivo, restano 42. Wiki SI-1_Reflect sez. 10.
* 2026-09-23 14:01 UTC ASSORBITO il cantiere 'chat-s20260923-claudesi1-nkfgid' (simile): obiettivo: Sessione S20260923-claudesi1-nkfgid: deliverable D1-D3 incompleti (lettura ultime uscite Hermes Daily, sintesi adozioni, handoff aggiornato) e commessa mai chiu | perche': chat S20260923-claudesi1-nkfgid chiusa senza prova: il custode R103 ha trovato passi eseguibili
* 2026-09-23 14:01 UTC ASSORBITO il cantiere 'chat-s20260923-claudesi1-nkfgid' (simile): obiettivo: Sessione S20260923-claudesi1-nkfgid: deliverable D1-D3 incompleti (lettura ultime uscite Hermes Daily, sintesi adozioni, handoff aggiornato) e commessa mai chiu | perche': chat S20260923-claudesi1-nkfgid chiusa senza prova: il custode R103 ha trovato passi eseguibili
* 23/09 sera: hermes_cases.py (SI-1-HERMES-CASI) porta le proposte Hermes senza decisione in SI-1 come casi HP-*, 2 per corsa, riga BQ marcata SI1
* provato con HP-prop_20260826_71e2a5. hermes_migliorie cron disattivato (#CONCENTRATO_SI1, crontab backup). Hermes Daily include blocco SI-1 (HERMES-DAILY-SI1)
* Telegram digest pendenti spento (DIGEST-TELEGRAM-OFF). Wiki sez. 11. VM riavviata da agent-watchdog alle 16:06 UTC per memoria: non SI-1.
; Provato ed escluso :
; Provato ed escluso :
* tool MCP safe_* non testabili da questa chat (connettore non caricato): la via HTTP con X-API-Key e equivalente e verificata
* tool MCP safe_* non testabili da questa chat (connettore non caricato): la via HTTP con X-API-Key e equivalente e verificata
; Prossimo passo :
; Prossimo passo :
* grep -c si1_finding /dev/null
* grep -nE "hermes_case|HP-|Traceback" /home/claudeuser/self_improvement/si1.cron.log | tail -10
* python3 /home/claudeuser/self_improvement/reflect.py --check
 
* leggere le ultime uscite Hermes Daily non ancora lette
=== gate-mcp-log-chat ===
* redigere D2: cosa adottare/applicato/messo in cantiere
''Aggiornato 2026-09-23 15:05 UTC'' — dominio: ingegnere
* aggiornare handoff (D3)
 
* commessa.py chiudi S20260923-claudesi1-nkfgid --esito COMPIUTO --consegna <file> --next <passo>
; Obiettivo : OGNI chat che tocca il sistema (Claude, ChatGPT, Gemini; MCP o VM; nuova o gia' in corso) dichiara OBIETTIVO FINALE (che cosa e' stato chiesto) e OBIETTIVO PARZIALE (che cosa sta facendo adesso) e lascia un log completo in BigQuery: sessione con scopo, ogni chiamata tool con session_id, STEP con parziale, chiusura R152. Fatto quando: (a) chat MCP-only senza sessione -> rifiuto dal bridge su ogni tool; (b) chat con sessione ma senza obiettivo -> blocco al primo comando con richiesta di dichiararlo (anche le chat vecchie: 'registrazione tardiva'); (c) query BQ mostra tutte le chat di una giornata con obiettivo finale, ultimo parziale e stato; la Guardia segnala su Telegram le anomalie e Marco puo' vedere/coordinare gli obiettivi in corso.
; Vincoli in vigore :
* Additivo: EMERGENZA-* libero
* cc_session_open unico tool senza sessione
* R102 invariato. Bridge = Cloud Run sheets-connector. gate.sh: backup .bak prima di toccarlo
* test con sessione finta prima di attivare. Nessuna cancellazione di log. Coordinare con R90 (commessa = obiettivo finale), R94/R95, R145, R152, R153. Deploy bridge in produzione: OK esplicito di Marco al momento.
; Fatto (con prova) :
* 23/09/2026: MRO v8.0 STEP 0 + R153 (registrazione al gate come prima azione) scritti
* rule nel grafo rule_1790175473222_2pk2ae
* wiki ops rules.md/log.md aggiornati. Marco ha approvato il piano a 3 livelli (msg R102 16d16f0d8ec6cdc54590b0ccd6b1d846fa9d989e).
* 23/09/2026: MRO v8.0 STEP 0 + R153
* rule grafo rule_1790175473222_2pk2ae
* wiki ops aggiornata. MISURATO sul giornale (7gg, isicnv_workflows.chat_sessions_log): 114 sessioni, 92 con START, 30 con STEP, 9 con END, 37 END_NONVERIFICATO
* nessuna auto/emergenza. Cioe': chi usa la VM viene registrato (R95 funziona), ma 4 chat su 5 non lasciano STEP e quasi nessuna chiude
* le chat MCP-only non compaiono affatto. Esiste gia' il campo scopo (session/open?scopo, file sessions/SID.scopo, commessa R90 auto al primo comando se c'e' scopo): e' la base per l'obiettivo finale. Manca l'obiettivo PARZIALE. Marco 23/09 (msg 16d16f0d + due vocali): 'la cosa piu' semplice e' che una chat dica il suo obiettivo: cosi' abbiamo il log, vediamo se e' conforme, possiamo coordinare piu' obiettivi
* e poi l'obiettivo parziale della situazione, questo e' sicuro'.
; Provato ed escluso :
* Affidarsi alla sola disciplina della chat (e' il buco attuale: le chat MCP-only sfuggono).
* Affidarsi alla sola disciplina della chat. Considerare 'registrate' le chat vecchie solo perche' passano dal gate VM: senza obiettivo dichiarato il log non dice che cosa fanno.
; Prossimo passo :
* LIVELLO 0 (subito, VM, piccolo): gate.sh - se la sessione non ha sessions/SID.scopo, il primo comando viene bloccato (rc 97, stile R102) con: 'dichiara OBIETTIVO FINALE e OBIETTIVO PARZIALE: python3 scripts/chat_journal.py --session SID --tipo OBIETTIVO --finale ... --parziale ...'
* vale anche per le sessioni gia' aperte (registrazione tardiva). chat_journal.py: nuovo tipo OBIETTIVO (scrive .scopo + riga BQ) e STEP con --parziale obbligatorio. Vista BQ v_chat_obiettivi: per sessione obiettivo finale, ultimo parziale, ultimo evento, stato. LIVELLO 1: bridge MCP - middleware session obbligatoria su tutti i tool tranne cc_session_open
* cc_session_open richiede scopo (obiettivo finale)
* log di ogni chiamata in isicnv_workflows.mcp_tool_log. LIVELLO 2: parola d'ordine giornaliera nel MRO richiesta da cc_session_open. LIVELLO 3: Guardia incrocia giornale+mcp_tool_log+gate_activity -> Telegram
* report giornaliero a Marco 'chat di oggi: obiettivo, parziale, stato' (base per coordinare obiettivi e verificarne la conformita').


=== contesto-aree-0923 ===
=== contesto-aree-0923 ===
Estratto da "https://wiki.marcoparet.com/wiki/Cantieri_aperti"