Sistema pagine pillar: differenze tra le versioni - Wiki Progetto di Ricerca Metodo Paret

Riga 15:

* MAI ripetere automaticamente un comando non idempotente: un timeout lato client puo' essere stato comunque eseguito lato server (rischio doppie esecuzioni). Mettere la guardia nel comando stesso (if pgrep ... then GIA_ATTIVO else lancia).

* se l'SSH verso hostgator risponde "Connection reset", e' throttling temporaneo: loop di retry ogni 5 minuti sulla VM, non a mano.

== ChatGPT e il connettore MCP: problema noto e soluzioni ==

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.

SOLUZIONI, in ordine di stabilita':

# 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.

# 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.

# 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) ==

@@ Riga 15: / Riga 15: @@
 * MAI ripetere automaticamente un comando non idempotente: un timeout lato client puo' essere stato comunque eseguito lato server (rischio doppie esecuzioni). Mettere la guardia nel comando stesso (if pgrep ... then GIA_ATTIVO else lancia).
 * se l'SSH verso hostgator risponde "Connection reset", e' throttling temporaneo: loop di retry ogni 5 minuti sulla VM, non a mano.
+== ChatGPT e il connettore MCP: problema noto e soluzioni ==
+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.
+SOLUZIONI, in ordine di stabilita':
+# 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.
+# 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.
+# 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) ==