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

1. Aprire la sessione (obbligatoria per i comandi VM, vale 8 ore): GET /session/open?chat=TUONOME → risponde {session: ID}
2. Eseguire sulla VM: POST /vm/exec-direct con body {"session":"ID","cmd":"..."} — solo comandi sotto i 60 secondi
3. Lavori lunghi: lanciare con nohup su un file di log in /tmp/pillars/ e rileggere il log dopo, oppure POST /vm/task
4. Memoria: GET /memory/search?query=...&top_k=5 e POST /memory/add {kind,title,text}
5. 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". 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. 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. 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). AGGIORNAMENTO v3.2 (29/08, pomeriggio): AUTO-SESSIONE. Se il client non passa il parametro session a cc_vm_exec o cc_vm_task, il bridge apre da solo una sessione via /session/open e la usa: il bootstrap circolare (serve la sessione per eseguire, ma serve eseguire per avere la sessione) non esiste piu'. Testato end-to-end: cc_vm_exec senza session esegue sulla VM. La chat coordinatrice ChatGPT puo' quindi operare in modo completo dal connettore; resta buona pratica chiamare cc_session_open una volta a inizio chat e passare l'ID (audit piu' leggibile), e restano OBBLIGATORI commessa, journal STEP, handoff e annuncio in bacheca prima di toccare un pid. Rollback del bridge se servisse: backup pre-patch in gs://isicnv-command-center-routes/backups/ (mcp-v3 e mcp-bridge, timestamp 20260829T134644Z per la v3.0 e 20260829T142125Z per la v3.1), da ripostare su POST /self-update.

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.

Regole nei gate deterministici (aggiornato 31/08/2026)

I gate vivono in /home/claudeuser/scripts/pipeline_completa.py (numeri R123-R137 dal coordinatore; R138-R144 da Marco e dai suoi libri di scrittura). Sintesi vincolante:

• R138 la regola del segreto: le pagine parlano di segreti e misteri (anche "trascendere l'abituale"), come minimo nella parte storica e con formule dirette ("il segreto è..."). Almeno 2 occorrenze; la frase su Paracelso/Fludd/alchimia/Egitto deve contenerle. Frase storica canonica: "Nelle radici storiche del magnetismo si ritrovano precedenti in Paracelso, Fludd e nei segreti degli antichi alchimisti; la Scuola legge questa linea in continuità con radici ancora più antiche, che riconduce agli antichi egizi e pratiche considerate sacre."
• R139 la cifra tangibile batte la percentuale: niente "fino al X%", "molti", "many" senza un numero vero nella frase.
• R140 il terzo rigo è l'apertura vera: niente preamboli meta nel primo paragrafo ("in questo articolo", "before we begin", "nowadays").
• R141 la parola più corta vince: via "utilizzare, effettuare, implementare, leverage, in order to"; frasi entro 30 parole.
• R142 ogni sigla spiegata alla prima occorrenza (esenti: MESMERISMUS, ISI-CNV, PNL, CNV).
• R143 la parola di potere è "perché": ogni invito all'azione porta la sua ragione nella frase.
• R144 rapporto dei pronomi: molto tu/voi, "noi" solo per la partnership, "io" al massimo tre volte.

Orientamenti vincolanti per il Concilio (richiedono giudizio, non regex): C2 titoli e immagini mostrano la soluzione, mai il problema; C5 ogni caratteristica (livelli, ore, moduli) porta accanto il suo beneficio; C9 ogni promessa ("imparerai") ha nel paragrafo una prova (numero, esempio, nome). Origine e meccanismi di verifica: wiki ops, pagina Regole_scrittura_libri.

Revisione e pubblicazione (regola di Marco, 31/08/2026)

Niente più cartelle preview-*. Una pagina in revisione vive già al suo URL definitivo, pubblicata con noindex (preview_pillar.py PID imposta il post meta _isicnv_preview=1, letto dal mu-plugin isicnv-pillar-seo.php). Pubblicare = pubblica_pillar.py --cluster NOME --lingue en=PID,it=PID,...: toglie il flag, imposta l'estratto (meta description), registra il gruppo hreflang nel mu-plugin, verifica dall'esterno (200, lang, title, canonical, noindex assente, meta description, hreflang, GA4, sitemap) e con un browser vero. Le altre lingue: traduci_cluster.py --sorgente PID --base slug --lingue fr,es,de,pt,ru,bg crea post nativi (slug -lang, meta _pll_lang) solo se passano il gate di qualità (H2 completi, parole ±30%, niente inglese residuo, MESMERISMUS® conservato).

Il secondo motore: espansione (attivo dal 29/08)

Il primo motore SCRIVE le pagine; il secondo decide QUALI scrivere, le misura e le arricchisce.

• STRATEGA (scripts/stratega.py, cron domenica 05:30 UTC): legge 90 giorni di query reali da Search Console sui due siti, le confronta col registro pagine, individua i cluster di domanda SENZA pagina dedicata e le pagine in posizione 5-25 da potenziare. Con --proponi aggiunge i 2 migliori candidati a coda_temi (marcati "proposta stratega"); con --questionario genera per il candidato di punta il QUESTIONARIO DI GROUNDING per Marco e lo crea come Google Doc su Drive (titolo "Questionario pillar - TEMA") oltre che su GCS docs/. Le risposte di Marco sono il materiale che nessun concorrente ha: la fabbrica non scrive un tema proposto finche' il questionario non e' compilato. Report: pillars/strategia_report.txt e GCS docs/strategia_report.txt.
• SENTINELLA ANALYTICS (scripts/bq_sink_cruscotto.py, cron 07:35 UTC, dopo il cruscotto delle 07:15): ogni giorno versa le metriche del cruscotto in BigQuery, dataset pillar_intelligence, tabella metrics_giornaliere (data, sito, pagina, impressioni, click, posizione, coorte, finestra). Il perimetro cresce DA SOLO: il registro pagine del cruscotto si estende automaticamente a ogni pagina pubblicata su WordPress. Idempotente sul giorno. Alert automatici in bacheca (mittente sentinella-analytics): calo impressioni >40 percento su pagina pillar, ingresso in top 10. Interrogazione: cc_bq_query o POST /bq/query su pillar_intelligence.metrics_giornaliere.
• ARRICCHITORE GEO/SEO (scripts/arricchitore.py, nella catena della fabbrica): scrivere bene non basta: la pagina deve avere ELEMENTI RICCHI per punteggiare in SEO e GEO. Pagella per pagina (arricchitore.py PID): almeno 1 VIDEO embed del Prof. sul tema, immagini con ALT descrittivo, DATI STRUTTURATI JSON-LD, liste citabili. Con --schema genera e inserisce Article + FAQPage JSON-LD (snapshot prima; annunciare in bacheca se la pagina e' live). Video e immagini restano scelte umane o della chat che rifinisce: la pagella dice DOVE mancano. Stato attuale: 6751 e 6828 sono senza video, immagini e JSON-LD - primo lavoro di arricchimento da fare.

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)