Cantieri aperti: differenze tra le versioni - Wiki Progetto di Ricerca Metodo Paret

Riga 8:

== Cantieri attivi ==

=== gate-mcp-log-chat ===

''Aggiornato 2026-09-23 15:02 UTC'' — dominio: ingegnere

''Aggiornato 2026-09-23 15:05 UTC'' — dominio: ingegnere

; Obiettivo : OGNI chat che tocca il sistema (Claude, ChatGPT, Gemini; MCP o VM) lascia un log completo ~~e verificabile~~ in BigQuery: sessione ~~aperta~~ con scopo, ogni chiamata tool con session_id, STEP, chiusura R152. Fatto quando: (a) ~~una~~ chat MCP-only senza ~~cc_session_open riceve~~ rifiuto dal bridge su ~~qualunque~~ tool cc_*/drive/wiki/mw_* (~~come /vm/exec 428~~) e (b) ~~una~~ query ~~su chat_sessions_log + log tool MCP~~ mostra ~~per una giornata intera~~ tutte le chat, ~~senza buchi,~~ e la Guardia segnala su Telegram ~~sessioni aperte senza STEP~~ e ~~chiamate senza sessione~~.

; 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-* ~~resta~~ libero

* Additivo: EMERGENZA-* libero

* cc_session_open ~~e' l'~~unico tool ~~che non richiede~~ sessione

* cc_session_open unico tool senza sessione

* R102 invariato. Bridge = Cloud Run sheets-connector ~~(route /vm/~~*~~, /session/open)~~. Nessuna cancellazione di log. Coordinare con ~~R95/~~R90/R145/R153 ~~gia' nel MRO v8~~.~~0. Modifica al~~ bridge in produzione: ~~backup della revisione Cloud Run prima del deploy~~.

* 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 1 (~~prima~~): ~~nel~~ bridge MCP, middleware ~~che richiede~~ session ~~valida~~ su tutti i tool tranne cc_session_open

* 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 ...'

* ~~senza -> risposta di blocco con istruzione~~ cc_session_open~~(chat,~~ scopo) (~~stesso stile del gate R102~~)~~. Loggare OGNI~~ chiamata ~~MCP (tool, session_id, ts, hash args)~~ in ~~BQ isicnv_agents~~.mcp_tool_log. LIVELLO 2: parola d'ordine giornaliera ~~scritta solo~~ nel MRO ~~(riga STEP 0, cron),~~ richiesta da cc_session_open ~~= prova di lettura del MRO~~. LIVELLO 3: Guardia incrocia ~~chat_sessions_log~~ + mcp_tool_log + gate_activity~~: sessione senza STEP entro N min, chiamate senza sessione, chat senza END~~ -> Telegram~~. Report~~ giornaliero '~~tutte le~~ chat di oggi' ~~a Marco~~.

* 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 ===

@@ Riga 8: / Riga 8: @@
 == Cantieri attivi ==
 === gate-mcp-log-chat ===
-''Aggiornato 2026-09-23 15:02 UTC'' &mdash; dominio: ingegnere
+''Aggiornato 2026-09-23 15:05 UTC'' &mdash; dominio: ingegnere
-; Obiettivo : OGNI chat che tocca il sistema (Claude, ChatGPT, Gemini; MCP o VM) lascia un log completo e verificabile in BigQuery: sessione aperta con scopo, ogni chiamata tool con session_id, STEP, chiusura R152. Fatto quando: (a) una chat MCP-only senza cc_session_open riceve rifiuto dal bridge su qualunque tool cc_*/drive/wiki/mw_* (come /vm/exec 428) e (b) una query su chat_sessions_log + log tool MCP mostra per una giornata intera tutte le chat, senza buchi, e la Guardia segnala su Telegram sessioni aperte senza STEP e chiamate senza sessione.
+; 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-* resta libero
+* Additivo: EMERGENZA-* libero
-* cc_session_open e' l'unico tool che non richiede sessione
+* cc_session_open unico tool senza sessione
-* R102 invariato. Bridge = Cloud Run sheets-connector (route /vm/*, /session/open). Nessuna cancellazione di log. Coordinare con R95/R90/R145/R153 gia' nel MRO v8.0. Modifica al bridge in produzione: backup della revisione Cloud Run prima del deploy.
+* 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 1 (prima): nel bridge MCP, middleware che richiede session valida su tutti i tool tranne cc_session_open
+* 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 ...'
-* senza -> risposta di blocco con istruzione cc_session_open(chat, scopo) (stesso stile del gate R102). Loggare OGNI chiamata MCP (tool, session_id, ts, hash args) in BQ isicnv_agents.mcp_tool_log. LIVELLO 2: parola d'ordine giornaliera scritta solo nel MRO (riga STEP 0, cron), richiesta da cc_session_open = prova di lettura del MRO. LIVELLO 3: Guardia incrocia chat_sessions_log + mcp_tool_log + gate_activity: sessione senza STEP entro N min, chiamate senza sessione, chat senza END -> Telegram. Report giornaliero 'tutte le chat di oggi' a Marco.
+* 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 ===