Sistema pagine pillar: differenze tra le versioni

[versione verificata]

← Differenza precedente Differenza successiva →

VisualeWikitesto

@@ Riga 19: / Riga 19: @@
 SINTOMO (osservato il 29/08): il discovery MCP riesce (25 tool elencati) ma la chiamata immediatamente successiva fallisce con "Resource not found: Command_Center_V3.wiki".
-CAUSA: il server MCP gira su Cloud Run che scala a zero: la sessione MCP e' legata all'istanza, e tra il discovery e la chiamata l'istanza puo' essere riciclata; il router di ChatGPT NON rifa' la discovery e chiama nel vuoto. L'errore "Resource not found" (e non "Tool not found") indica inoltre che il client cerca il tool tra le resources: in alcuni contesti ChatGPT ai connettori e' permesso solo search/fetch. Il problema NON e' nelle credenziali ne' nel Command Center.
+DIAGNOSI VERIFICATA (29/08, test diretto sul bridge): il bridge MCP (/mcp-v3 su sheets-connector) e' GIA' STATELESS — initialize, tools/list e tools/call funzionano da connessioni separate senza sessione. Il blocco e' nel CLIENT ChatGPT: in chat normale i connettori possono invocare solo tool chiamati "search" e "fetch"; gli altri vengono elencati dal discovery ma rifiutati all'invocazione ("Resource not found" e' il messaggio di ChatGPT, non del server). Credenziali e Command Center non c'entrano.
-SOLUZIONI, in ordine di stabilita':
+RISOLUZIONE APPLICATA (29/08, bridge v3.1): al bridge sono stati AGGIUNTI i tool "search" e "fetch" nel formato che ChatGPT accetta in chat normale. search interroga wiki di lavoro + memoria CC (con timeout: se la memoria e' lenta rispondono comunque i risultati wiki); fetch recupera il contenuto per id ("wiki:TITOLO" o "mem:ID"; un titolo wiki nudo vale come wiki:TITOLO). Quindi la chat coordinatrice ChatGPT puo' LEGGERE tutto il sistema (manuale, bacheca, cantieri, memoria) attraverso il connettore stesso, anche quando il suo browser fallisce.
-# ChatGPT in modalita' READ-ONLY: legge manuale, bacheca e cantieri dagli URL pubblici del wiki (GET con browsing) e produce piani, testi e istruzioni; l'esecuzione la fa una chat Claude o Marco. E' la modalita' gia' prevista dal prompt standard.
+PER L'ESECUZIONE COMPLETA (cc_vm_exec, wiki edit, ecc.) dalla chat ChatGPT: serve la modalita' sviluppatore dei connettori MCP di ChatGPT (impostazioni dell'account ChatGPT, lato OpenAI: non dipende da noi); in alternativa un custom GPT con Actions sullo schema OpenAPI "openapi_command_center.yaml" (nel Project Claude). Con la modalita' sviluppatore attiva valgono per ChatGPT gli STESSI obblighi delle chat Claude: cc_session_open a inizio chat, commessa aperta al primo comando, journal STEP, handoff a milestone (vedi sotto).
-# Custom GPT con Actions (la via stabile per scrivere): importare lo schema OpenAPI "openapi_command_center.yaml" (consegnato a Marco il 29/08, anche nel Project Claude) nelle Actions di un GPT dedicato, con API key nell'header X-API-Key. Le Actions fanno POST diretti a /session/open, /vm/exec-direct, /memory/*: nessun MCP di mezzo, nessuna sessione che si perde.
+Rollback del bridge se servisse: backup pre-patch in gs://isicnv-command-center-routes/backups/mcp-v3.20260829T134644Z.json (e mcp-bridge stesso timestamp), da ripostare su POST /self-update.
-# Riprovare l'MCP in un momento di traffico (il servizio caldo non scala a zero) o dopo che il server MCP sara' reso stateless.
 == Coordinamento tra chat (interchat) ==