Sistema pagine pillar

Il sistema che crea e mantiene le pagine SEO+GEO di marcoparet.com senza perdere elementi utili, con lavoro coordinato tra piu' chat e piu' modelli (Claude, ChatGPT, Gemini). Aggiornato al 28/08/2026, sera.

Accesso per QUALSIASI modello (anche ChatGPT)

Tutto passa da HTTPS. Base: https://sheets-connector-424757051842.europe-west1.run.app — header obbligatorio su ogni chiamata: X-API-Key: fb17164b09be4b32bfd082ccd54ff651

Aprire la sessione (obbligatoria per i comandi VM, vale 8 ore): GET /session/open?chat=TUONOME → risponde {session: ID}
Eseguire sulla VM: POST /vm/exec-direct con body {"session":"ID","cmd":"..."} — solo comandi sotto i 60 secondi
Lavori lunghi: lanciare con nohup su un file di log in /tmp/pillars/ e rileggere il log dopo, oppure POST /vm/task
Memoria: GET /memory/search?query=...&top_k=5 e POST /memory/add {kind,title,text}
Task aperti: GET /jobs/list?status=TODO — problemi noti: GET /learnings/check?symptom=...

Regole d'oro per l'API, imparate sul campo il 28/08:

comandi CORTI: i payload lunghi possono dare Service Unavailable. Per caricare un file: spezzarlo in blocchi base64 numerati scritti ciascuno col proprio nome (mtc_000, mtc_001...) e ricomporre con cat mtc_* | base64 -d — i blocchi numerati sono riscrivibili senza rischio di doppioni.
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)

La bacheca dei messaggi tra chat e' https://wiki.marcoparet.com/wiki/Bacheca_interchat (lettura pubblica via GET, anche per ChatGPT). Scrivere e leggere dalla VM: python3 /home/claudeuser/scripts/interchat.py invia --da MIACHAT --a DESTINATARIO --oggetto "..." --msg "..." | leggi --per MIACHAT | bacheca Ogni messaggio arriva su tre canali: memoria CC (kind interchat), pagina wiki, file su VM.

REGOLA ANTI-COLLISIONE (nata da una collisione reale il 28/08): prima di modificare un post WordPress, leggere la bacheca e ANNUNCIARE il lavoro; mai due chat sullo stesso pid nello stesso momento. Snapshot sempre in /home/claudeuser/pillars/snapshots/ prima di modifiche importanti.

Stato dei lavori: https://wiki.marcoparet.com/wiki/Cantieri_aperti — a ogni milestone: python3 /home/claudeuser/scripts/handoff.py --write --id CANTIERE --fatto "..." --prossimo "..."

La catena di produzione (script in /home/claudeuser/scripts/)

fabbrica_pagine.py --una — prende il primo tema non fatto da /home/claudeuser/pillars/coda_temi.txt (formato: titolo | slug | keyword | note vincolanti), raccoglie materiale dalla memoria, scrive la pagina con le regole della casa e crea una BOZZA WordPress. Non pubblica MAI. Gira anche da cron il lunedi' alle 05:00 UTC.
inventario_protetti.py PID --salva — da eseguire PRIMA di ogni potatura: censisce citazioni dirette, entita' del lignaggio, sezioni con ruolo unico (conversione, sicurezza, lignaggio), note e link.
potatura_sicura.py PID --applica — involucro del potatore: snapshot, inventario, potatura, diff di perdita, archivio dei tagli in /home/claudeuser/pillars/scorpori/ (nessun taglio muore), ripristino automatico se si perde un elemento protetto.
diff_perdita.py vecchio.html nuovo.html — dice che cosa si e' perso tra due versioni: sezioni, citazioni, entita', frasi.
architetto.py PID [--esegui] — decide se un tema merita sezione, pagina o cluster. Mai scorporare il tema-cuore (quello nel titolo della pagina). Con --esegui crea la bozza scorporata e lascia un segnaposto; dopo la pubblicazione: architetto.py PID --collega SLUG.
dedup_frasi.py PID — frasi ripetute identiche o quasi.
guardiano_grassetti.py PID --report — densita' e distribuzione dei grassetti (banda: uno ogni ~13 parole su sintagmi sensati).
rilettore.py PID — controllo qualita' redazionale. ATTENZIONE: tarato per pagine italiane; su pagine inglesi il rilievo CITAZIONE NON TRADOTTA e' un falso positivo.
controllo_coda.py PID [--sezioni N] — OBBLIGATORIO prima di chiudere qualunque pagina: legge le ultime sezioni DAL BASSO (le code accumulano ripetizioni e link rotti che i controlli dall'alto non vedono): dedup contro tutta la pagina, verifica HTTP dei link di coda, chiamata AI dedicata alle sole sezioni finali. Nota: segnala anche la ridondanza FAQ-vs-sezioni, che in ottica GEO e' spesso voluta — valutare caso per caso.
WordPress si comanda via ssh hostgator dall'interno della VM (chiavi gia' a bordo): wp post get/update/create. Senza l'ok esplicito di Marco si creano solo BOZZE: la pubblicazione e' sempre umana.

Regole editoriali (sintesi vincolante)

Banda 1800-2200 parole, ma la sostanza vince sulla banda. H2 formulati come le domande reali degli utenti (prendere le query da Google Search Console, non inventarle). Grassetti: uno ogni ~13 parole, mai frasi intere. Citazioni dirette solo reali, tra virgolette basse con attribuzione. Niente promesse terapeutiche; sempre una sezione su ambito e limiti. Uno o due elenchi puntati (le AI li citano). FAQ con 4 domande. Note numerate a pie' di pagina con fonti. Link interni solo a pagine VERIFICATE esistenti. Chiusura con il paragrafo sui seminari dal vivo e l'Universite Europeenne. I tre rami polivagali si spiegano UNA volta sola per pagina. Nessun taglio va perso: tutto negli scorpori. Il tema che coincide col titolo della pagina non si scorpora mai.

Stato al 28/08/2026, sera

https://marcoparet.com/crisi-mesmerica/ — DEFINITIVA (pid 6751, redirect 301 dal vecchio slug versione-b)
https://marcoparet.com/le-due-forme-del-magnetismo/ — pubblicata (pid 6818), scorporo con lignaggio Di Pisa
Bozza pid 6820 (ciclo-delle-tre-crisi, satellite) — DECISIONE APERTA di Marco: pubblicare o cestinare
Bozza pid 6828 (mesmerism-training, inglese, costruita sui dati GSC: cluster ~350 impressioni) — resta bozza: serve grounding col questionario Q1 (in mano alla chat brand) e poi la pubblicazione di Marco
Versione A (crisi-mesmerica-liberazione, pid 6747) — proposta: redirect 301 sulla definitiva; DECISIONE APERTA
Coda temi fabbrica: catalessi (il tema Arkeos NON va in fabbrica: la pagina arkeos-direttore-interno esiste gia', va potenziata)