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 16:17 UTC'' — dominio: ingegnere
; Obiettivo : OGNI chat (Claude/ChatGPT/Gemini, MCP o VM, nuova o in corso) dichiara obiettivo finale + aree e lascia un log completo: sessione con scopo, ogni comando con PASSO (R155), ogni chiamata MCP con session_id, chiusura R152. Fatto quando: chat MCP-only senza sessione rifiutata dal bridge; query BQ mostra tutte le chat di un giorno con obiettivo, ultimo passo, aree, stato; Guardia segnala anomalie; report giornaliero per area.
; Vincoli in vigore :
* Additivo
* EMERGENZA-* libero
* cc_session_open unico tool senza sessione
* R102/R155 invariati. MAI aggiungere righe a gate.sh (si rompe): estensioni in script separati agganciati da tracce.py/gate_pipeline.py. Nessuna cancellazione di log.
; 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'.
* 23/09 18:15: LIVELLO 0 = R155 REGISTRO PASSI FATTO e verificato (blocco senza PASSO
* riga con msgid su BQ passi_chat
* cron carica). MRO: STEP 0 fuso (scopo+aree+contesto+PASSO), R153, R155. Wiki ops rules/log. Misura 7gg pre-R155: 114 sess, 30 con STEP, 9 con END.
; 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.
* Affidarsi alla disciplina della chat.
; Prossimo passo :
* LIVELLO 1 sul bridge Cloud Run sheets-connector: /session/open accetta aree= (11 aree contesto_area.py), le propone dallo scopo se mancano (compilatore assistito), risponde con altre chat attive nelle stesse aree
* middleware che rifiuta ogni tool senza sessione
* mcp_tool_log. Backup revisione Cloud Run
* OK Marco al deploy. LIVELLO 2 parola d'ordine MRO. LIVELLO 3 chat_messages + Guardia + report giornaliero per area. Dettagli: /home/claudeuser/handoffs_aree_proposta.md
=== si-1-automiglioramento ===
=== si-1-automiglioramento ===
''Aggiornato 2026-09-23 16:13 UTC'' — dominio: VM / infrastruttura
''Aggiornato 2026-09-23 16:13 UTC'' — dominio: VM / infrastruttura
Riga 72: Riga 104:
; Prossimo passo :
; Prossimo passo :
* grep -nE "hermes_case|HP-|Traceback" /home/claudeuser/self_improvement/si1.cron.log | tail -10
* grep -nE "hermes_case|HP-|Traceback" /home/claudeuser/self_improvement/si1.cron.log | tail -10
=== 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').


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