Cantiere

Ogni mattina alle 6 (un lavoro per cliente) il cervello legge 5 pianeti (Booking, CRM, Sales, Web, Content), li confronta con i parametri di settore e genera 3-6 osservazioni. Content entra anche nella chat e nella memoria del Sole (PR #270/#272). Trova colli di bottiglia concreti: clienti a rischio abbandono, trattative ferme, troppe cancellazioni, contenuti generati ma mai pubblicati.

→ dove si espande: Marketing: entra nel ragionamento quando avra un data layer (oggi nessuna tabella ads, ometterlo evita dati finti).

Il cervello propone o esegue azioni: recupero clienti persi, richieste di recensione, follow-up via email, bozze di contenuti. Ogni cliente sceglie l'autonomia (spento, proponi, automatico). Le prime esecuzioni sono gia avvenute davvero. 06-06 (#302 MERGIATO): le azioni non sono piu uno sweep cieco ma seguono il PIANO DI CRESCITA - il Sole esegue le LEVE del collo del momento (chiude il ciclo senti->pianifica->agisci). Ogni run e legata al collo in telemetria (bottleneck + leve pianificate + leve senza esecutore ancora). Esecuzione sul backbone deterministico (manda email reali); le leve advisory (assumere, prezzi, ads) restano consiglio. 06-06 (#313 MERGIATO): aggiunti i 3 esecutori mancanti -> ORA OGNI leva eseguibile del piano ha un esecutore. publica/programma contenuti pronti (content.publish_pending: materializza una generation ferma in un contenuto programmato, sblocca il collo distribution, NON auto-posta), follow-up trattativa (sales.followup) e sblocca trattativa (sales.unstick) (email sovrana EU dalla casella del cliente, gated da autonomia, idempotente, honest skip senza SMTP).

→ dove si espande: Allargare il catalogo per-settore (oggi le azioni sono trasversali ai 7 settori top).

Decide, pianeta per pianeta, se un'azione va solo proposta o eseguita in automatico, con interruttore di sicurezza. Centralizzato e affidabile.

Il motore comune che fa girare gli agenti AI con un ciclo controllato, conta i token e gestisce gli errori in sicurezza. Il mattone su cui poggia tutto il cervello.

Come il cervello ricorda fatti, episodi e schemi su ogni azienda. LIVE in produzione (verificato sul DB 2026-06-05): chiave Voyage attiva, embedding voyage-4-large a 1024 dimensioni, indice HNSW, richiamo ibrido (significato x importanza x recenza) gia collegato alla chat del Sole. 45 ricordi su 57 vettorializzati. Un passo di backfill notturno ripara i ricordi rimasti indietro (PR #256).

→ dove si espande: Estendere il consumo della memoria oltre la chat del Sole (oggi e l'unico consumatore); pacchetti di settore.

Voce coerente, adatta al ruolo di chi legge (titolare o collaboratore), al settore e alla lingua (4 lingue). Non un testo fisso ma un'identita per ogni azienda.

Si fa una domanda al Sole e lui risponde sui dati reali dell'azienda (ricordi + numeri + osservazioni), poi salva lo scambio in memoria.

La scheda 'Diario' dell'AI Hub: la cronaca giorno per giorno di cosa il Sole ha osservato, proposto ed eseguito per l'azienda, con l'esito reale e il link alla schermata giusta. Costruita solo su dati gia salvati (corse agente, decisioni, insight, eventi, notifiche), 4 lingue, zero costo AI. E la prova navigabile che l'app lavora da sola (PR #388 MERGED, 2026-06-21).

Decisione founder 2026-07-03 (v205): il tempo e una dimensione trasversale, non un dominio -> vive nel Sole come QUINTA funzione dell'hub (accanto a Chat, Memoria, Strategia, Obiettivi). Vista calendario unificata del FUTURO, gemella del Diario (che copre il passato): aggrega read-only le date gia esistenti nei pianeti (prenotazioni, post programmati, richiamate/appuntamenti Sales, campagne/invii Marketing, follow-up) con filtri per pianeta e deep-link. Zero migration (pattern Diario). Scartate al panel (3 lenti unanime): Booking->satellite del Web (rompe pricing Starter Light senza Web + pitch anti-commissioni + declassa il pianeta piu completo) e Pianeta Calendario aggregatore (secondo Sole, rompe la regola pianeta=dominio che produce dati). Percorso evolutivo: Fase 1 Agenda read-only + obiettivi consolidati su planet_goals + bonifica CalendarPage (fonte morta deals.meeting) -> Fase 2 l'Agenda scrive (crea appuntamenti/scadenze cross-pianeta) -> Fase 3 promozione a pianeta SOLO se produce dati propri (pattern planned di PLANET_CATALOG). Booking resta pianeta in ogni scenario. Andamenti restano Home + rollup Finanza + Galassia (non duplicati qui). FASE 1 COSTRUITA 2026-07-08 (PR Multiverbe#558, born-green): endpoint GET /api/ai/agenda + normalizzatore puro buildAgenda (6 sorgenti future, i18n 4 lingue, 13 test) clonati dal Diario (stessa auth Bearer+team_members, zero migration) + tab Agenda nell'hub AI (griglia mese Nebula Glass, filtri per pianeta, deep-link Sales incluso, read-only) + bonifica: rimossa CalendarPage (leggeva deals.meeting inesistente) montata per errore sul Content -> satellite Calendario del Content ora punta al calendario editoriale vero (social_posts). Gate verdi (tsc0/lint 519<560/knip0/depcruise0/2417 test/build). Verificato contro lo schema di PROD: le 6 query girano, 4 prenotazioni future reali si normalizzano OK. **PR #558 MERGED 2026-07-08 -> master 4c3d1764 (squash, auto-deploy multiverbe.app)**; branch+worktree ripuliti. RESTA: look live sull'OLED (l'hub si apre cliccando il Sole 3D -> preview headless NO R3F) + Fase 2 (Agenda che scrive impegni cross-pianeta).

→ dove si espande: Fase 2: scrittura dall'Agenda (l'evento nasce li e finisce nel pianeta giusto).

Usare modelli diversi per compiti diversi (Sonnet 60%, Haiku 30%, Opus 10%). Sede unica di routing (routeModel) con scavalco via variabile d'ambiente, PR #258. Il routing odierno e gia corretto per natura del task: tutti i consumi live sono user-facing, ragionamento o deduzioni one-shot, quindi Sonnet. Il 60/30/10 e un esito, non una quota da forzare.

→ dove si espande: Accendere i tier Haiku (classificazione a volume) e Opus (planner strategico) quando esistono quei consumi reali.

OBIETTIVO PRINCIPALE: il Sole vede tutti i pianeti e trova ed esegue le COMBINAZIONI di leve che fanno crescere il business (piu clienti, piu valore), partendo dal collo del momento (es. Booking vuoto -> Content+Marketing su quelle fasce). Legge tanti segnali: domanda/occupazione, conversione, contenuti, lead, reach, e ANCHE la capacita (una leva in piu, non la testata). Capacity-aware: quando si e troppo pieni consiglia di crescere la CAPACITA (assumere, secondo turno/sede, prezzi), non altra domanda. Topologia hub: ottimizzazione globale. Vincoli deterministici (il floor), creativita LLM (il soffitto Opus). 06-06: il floor era live (#289/#294); ORA il SOFFITTO STRATEGIST OPUS e CABLATO sopra il floor (#299 MERGIATO): l'LLM riprioritizza/arricchisce le leve, sempre validato dall'engine (veta l'infattibile, ripiega sul floor). Due ingressi: on-demand (GET /api/growth/plan ora usa world-model COMPLETO con memoria/recall + voce/lingua del Sole) e cron del mattino (analyze-planet-data pre-calcola il piano per cliente e lo mette in cache Upstash 24h -> l'endpoint serve la cache tutto il giorno, niente ricalcolo ne costo ripetuto). Guardrail costo a regola d'arte: cap per-cliente/giorno (GROWTH_STRATEGIST_DAILY_CAP, default 3, contato su agent_runs) + interruttore globale (GROWTH_STRATEGIST_ENABLED). GATED OFF di default = ZERO costo finche il founder non accende. 681 test verdi (14 nuovi: cap, interruttore, cache-hit, memoria nel prompt), advisor 0 errori, ZERO migrazioni (riusa Upstash + agent_runs). Prod verificata sana (401 sull'endpoint, deploy pulito). PII-free: allo strategist arrivano solo aggregati + memoria gia pseudonimizzata.

→ dove si espande: Restano: (1) ACCENSIONE founder = flip env in Vercel prod (GROWTH_STRATEGIST_ENABLED=1, opz. GROWTH_STRATEGIST_DAILY_CAP) + giro di verifica del diff floor<->strategist su un cliente reale = decisione costo (margine 95%, bassa frequenza); (2) ESECUZIONE automatica delle leve: FATTA per le azioni mappate (#302 - sole-actions ora plan-driven: il collo del piano guida winback/recensione/follow-up/bozza, propose+auto dove planet-autonomy='auto'); COMPLETATA con #313 = aggiunti gli ultimi esecutori (pubblica/programma contenuti content.publish_pending, follow-up sales.followup, sblocca sales.unstick) -> ogni leva eseguibile del piano ha ora un esecutore; (3) pannello limiti operativi editabili dal titolare (migrazione additiva + UI, con sessione Booking); (4) UI 'Come far crescere' che consuma /api/growth/plan = FATTA (#325, tab Strategia AI Hub, CI verde, pending merge founder · prossimo: CTA per-leva + embedding Home); (5) copy.ts email del Sole de/fr/en (sessione copy dedicata).

Il pianeta piu completo: prenotazioni adattive per settore, zero commissioni, promemoria automatici e notifiche multicanale. Ha gia dati reali in produzione. Pronto per il lancio.

Contatti, cronologia, valore cliente, fidelizzazione, messaggi. Solido e con dati reali. 2026-06-21: due salti reali. (a) Il valore cliente non e piu finto: la mini-curva LTV mostra la serie storica vera, due viste mensili di database (PR #386 MERGED + migration applicata). (b) Loop NPS/feedback chiuso: il titolare chiede un feedback via email con link a token firmato, il cliente risponde da una pagina pubblica 0-10 in 4 lingue, dashboard NPS con punteggio/andamento/commenti (PR #389 MERGED + migration applicata). 2026-06-22: predittore di abbandono INTEGRATO (PR #402): calcolatore RFM-T 0-100 spiegabile + batch giornaliero (sfrutta analyze-planet-data delle 06:00, nessun nuovo cron) + vista segnali crm_contact_signals_v + tabella crm_contact_scores + badge 'Rischio medio/alto' nella directory contatti. Migration 2026-06-22c GATED: il founder la applica in prod (Supabase), il batch e fail-soft finche assente e il badge degrada in silenzio. 2026-06-22 (PR #407): insight churn del Sole ora BAND-AWARE - usa le bande RFM-T per-contatto (clienti di valore a rischio in cima, non il solo conteggio dei dormienti), dentro analyze-planet-data, riusando una sola lettura+calcolo per tabella E insight; fail-soft al conteggio finche la migration non e applicata; PII-free verso l'agente.

→ dove si espande: Applicare la migration churn 2026-06-22c in prod (accende il churn band-based reale + il badge rischio) + estendere il loop NPS con trigger automatici.

Generatore di sito + analisi, SEO e presenza locale. Motore robusto. Conformità completa e IN PRODUZIONE senza avvocato (privacy/cookie/banner consenso/Impressum/DPA/ToS a nome del cliente, 4 lingue, modello owner-responsibility + SCC UE; 13 PR + review big-tech, 2026-06-04). Satellite Recensioni COSTRUITO e LIVE su master (feed multi-portale, import CSV, bozze del Sole, avvisi/insight, vetrina sul sito con gate art.321; rifiniture copy 5 lingue + Stryker #553; invito recensione per-contatto ai promoter NPS con email reale + redirect firmato #4c/#551, inerte finché GBP non collegato). Restano in corso gli altri satelliti (Email Hub, Blog, Mappa di calore). 2026-06-22 (PR #409): 2a costituzione di design gold-standard = parrucchiere (hair-salon), oltre al ristorante (era il gap #1 del moat). Corretto alla radice il wiring settore->constitution (era keyed sul sector_id ma alimentato col business_type grossolano -> non matchava mai, tutto cadeva su 'restaurant'): ora useWorkspace espone sector_id e il wizard mappa sul settore vero (parrucchiere->hair-salon). Migration seed 2026-06-22d GATED.

→ dove si espande: EPIC 'qualita estrema per stravolgere il mercato' (decisions-log v167 · AVVIO 2026-06-24): Fase 1 IN CORSO = AUDIT siti esterni (URL -> crawl + PSI lab + CrUX field + GA4/GSC connessi + Reach Score esteso a dominio esterno -> report white-label + fix list impatto x effort; riusa safe-fetch SSRF/Reach/ai-visibility; founder-gated: Google API key PSI/CrUX + OAuth GA4/GSC). Backlog 'da fare' (ordine confermato dal founder): Fase 2 Conversione+Multilingua (cabla booking via proxy same-origin -> widget-create + costruisci form contatto/lead + newsletter -> CRM/Booking/Email Hub + notifica titolare; step Lingue nel wizard -> DE/FR/EN, backend gia pronto) · Fase 3 Editor AI-first (manipolazione diretta + assist AI scoped, migration site_block_revisions) · Fase 4 Analytics PIXEL SOVRANO mvb.js (migration web_hub_events+oauth_tokens, inietta consent-gated col fix chiave consenso, UI, connettori GA4/GSC/GBP) · Fase 5 GEO estremo (stats+fonte+citazione, answer-first 40-60 parole, schema Service/areaServed/FAQPage-da-contenuto-reale, localize non translate) · Fase 6 settori mancanti (13/21). Laterale: aggancio/attach widget a siti esterni (embed/API, scaffolding parziale, post-audit). --- 2026-06-24: 8 costituzioni gold-standard ATTIVE in prod (ristorante, parrucchiere, gym, studi professionali, estetica, agenzia immobiliare, hotel/B&B, SANITÀ medico/dentista/fisio/psicologo). GATE SANITARIO COMPLETO e LIVE su 3 strati (PR #427+#436+#437 MERGED, migration 2026-06-24e APPLICATA+verificata in prod): un sito sanitario (1) NON va 'published' senza una revisione legale umana confermata (publishingGate data-driven, blocco fail-closed 422, site_legal_reviews owner-only RLS, banner+CTA firma nel wizard), (2) viene GENERATO conforme in OGNI lingua (regole anti-pubblicita sanitaria iniettate nel prompt IT/DE/FR/EN tramite SSoT aggiornabile regulated-compliance.ts + test interni che bloccano la build se si toglie una protezione, es. recensioni), (3) se MODIFICATO dopo l'approvazione richiede una NUOVA revisione (l'approvazione copre solo il contenuto firmato, migration-free). Azioni founder su questo fronte: NESSUNA. Prossime costituzioni col medesimo pattern: bar, macro vendita/creativi/eventi + completare i satelliti (Email Hub, Blog, Recensioni, Mappa di calore).

Catena outbound completa (12 giu) + motore lead-gen Fase 1 (22 giu, 4 PR gate-verdi): satellite Lead con funnel, import/export CSV, outreach collegato, coda chiamate. Lead-gen sovrano zero-key: il Sole deduce l'ICP dal settore, trova aziende reali via OpenStreetMap/Overpass nel raggio, fit-score firmografico, coda candidati -> approva (con email estratta dal sito) -> lead; mappa MapLibre + PMTiles self-hostati. Restano caselle SMTP founder per l'invio reale.

→ dove si espande: Founder: caselle SMTP (invio reale) + GEOAPIFY_API_KEY su Vercel + upload tiles .pmtiles. Poi Fase 2: registri EU (Dealfront/Cognism), UI sotto-account venditori.

Testi e immagini con AI sovrana europea (Gemini/Imagen EU). 2026-06-06: chiuso il loop genera->consegna (PR #262). Prima il bottone Approva non salvava NULLA (drift valori vs CHECK di social_posts: insert respinto + catch muto -> 0 righe, calendario vuoto). Ora: salvataggio reale + programmazione (data/ora -> scheduled_at) + calendario che mostra i post + 'Segna come pubblicato' 1-tap + worker promemoria onesto (cron 15m -> nucleo_events publish_due). 2026-06-22 (PR #406 MERGED): il promemoria ora RAGGIUNGE il titolare invece di restare un segnale interno -> notifica azionabile in campanella 'e ora di pubblicare', click-through che apre il Calendario sul post, e la categoria e silenziabile in Impostazioni (campanella + push). Sempre onesto: NON segna 'posted'. Restano: auto-post sui canali (richiede API Meta/LinkedIn + OAuth, post-gate), video/voce, consolidamento social_posts->content_items.

→ dove si espande: Auto-post canali (API Meta/LinkedIn) = ultimo pezzo del loop (poi il promemoria diventa ridondante per quel canale), portarlo nel cervello, video+voce, far girare su casi reali.

MISURA in prod (PR #322 merged): cockpit ROI (campagna->ricavo), link tracciati cookieless /r/<slug>, pagelle vs benchmark di settore (loop verso Content), feed insight nel Sole. Disponibile DA PRO (non piu solo Business). [AUDIT CODICE 2026-06-29: il BOS SOTTOSTIMAVA — newsletter (Brevo reale, consent+cap+unsub), distribuzione assistita (prepare/launch/list), ads-advisor (deterministico, tabella ad_recommendations) e azione Sole promo_empty_slots sono GIA COSTRUITI e cablati in UI. Verificato 68%, non 50%. Veri gap: 0 righe in prod (mai girato end-to-end, pre-revenue + Vercel 402) + nessun layer ads-SPEND/ROAS (ROAS=0 by design) + Meta IG-insights read-only dormant dietro App-Review Meta.]

→ dove si espande: Step 3 azioni Sole + Meta adapter read-only + distribuzione/newsletter/ads + live test (task delegato). --- 2026-07-03 RICERCA MOTORE MARKETING (PR #16, 2 documenti): oltre alla MISURA gia in prod, il Pianeta Marketing evolve nel CERVELLO di marketing-intelligence che centralizza tutti i dati in input, ne capisce andamenti e cause, e propone le azioni. Roadmap in 7 moduli qualita-first: Single Source of Truth dati -> Semaforo di efficienza -> Motore diagnostico 'il perche' -> Creative intelligence -> Guardian anomalie e budget -> Allocatore di budget -> Copilota neutrale e benchmark. Angolo di leadership: progettato per la BASSA-VOLUMETRIA della PMI locale, dove le soglie enterprise/DTC USA non si raggiungono. Svizzera-first, Europa-ready. Fonti operative: execution/research-marketing-intelligence-2026.md (il cervello) + execution/research-digital-ads-youtube-2026.md (esecuzione ads). Prossimo passo: mini-spike build-vs-buy del layer dati/tracking (decisione 2C), poi build del Modulo 1 nella sessione codice (handoff-2026-07-03-motore-marketing.md).

APPLICATO E LIVE in prod nel solo workspace interno Multiverbe (2026-06-24, migration c+d + hardening g via MCP; VERIFICATO: solo Multiverbe allowlistato a livello globale, 2 carte, 21 voci di costo reali, burn mensile CHF 278, 6 servizi sulla carta 9808 che fallisce; advisor security 0 ERROR e 0 WARN introdotti da Finanza). AVVIATO 2026-06-24 per dogfooding interno (decisione founder). Scopo: registro vivo dei costi aziendali + scadenzario 'cosa pago e quando' + allarmi carta-che-fallisce, per ogni utente Multiverbe. Non e cassa/POS ne partita doppia: e costi + scadenze. Moat: import automatico dalle fatture email (il lavoro fatto a mano oggi). MVP INTERNO COSTRUITO lo stesso giorno, born-green (PR #429, merge+migration=founder): 7o pianeta 3D ORBITANTE reso nella scena (lime, orbita esterna kepleriana) + fallback 2D, ma WORKSPACE-GATED via allowlist finance_enabled_workspaces a livello RLS (workspace-isolation AND is_finance_enabled) + gate client useFinanceEnabled fail-soft -> visibile + dati SOLO nel workspace interno Multiverbe, invisibile a ogni altro tenant. Migration additiva 2026-06-24c (finance_payment_methods + finance_cost_entries + allowlist + RLS + is_finance_enabled SECURITY DEFINER + indici + trigger) + seed 2026-06-24d (workspace risolto per owner-email senza UUID hardcoded, 2 carte 9808-failing/6073-ok, costi reali da stack-costi-pagamenti.md) APPLICATE+VERIFICATE in prod 2026-06-24 + hardening 2026-06-24g (is_finance_enabled spostata nello schema private, advisor pulito). Endpoint api/finance: overview (burn mensile normalizzato, breakdown categoria, scadenze 30/60/90 con flag su-carta-che-fallisce, allarmi carta -> servizi a rischio, prepagati) + CRUD costi/carte, gate fail-closed. UI FinanzaSurface a 4 satelliti (Costi/Scadenze/Carte/Categorie), it/de/fr/en, accessibile, KPI di testata reali. Il Pianeta ha ora i dati veri dentro il sistema (supera la pagina /costs del BOS).

→ dove si espande: FATTO: #429 mergiato born-green + migration c+d+g applicate e verificate in prod (pianeta LIVE nel workspace Multiverbe). RESTA al founder: (1) rigenerare src/types/supabase.ts (ora che le finance_* sono in prod -> chiude il check schema-drift, che copre anche il drift pre-esistente MFA); (2) verifica live (login workspace Multiverbe -> il 7o pianeta lime appare, i 4 satelliti coi dati veri, assente negli altri workspace). Apertura ai clienti ~agosto 2026 = un INSERT nella allowlist (niente migration di schema). Moat post-MVP: import automatico dalle fatture email + edit-in-place delle voci.

RISOLTO 2026-06-04 (PR Multiverbe#175 mergiata, CI verde): i numeri di testata di Booking, CRM, Sales e Web ora sono REALI, da un nuovo endpoint /api/planets/metrics (solo aggregati, zero dati personali). Tolte le sparkline finte. Content/Marketing/AI non hanno ancora dati e mostrano '—' onesto (non piu finto).

→ dove si espande: Quando Content/Marketing avranno dati reali, aggiungere anche i loro KPI.

La procedura attuale, attiva di default. Funziona.

Versione migliore con 28 settori in 6 macro e aiuto AI che deduce il settore da una descrizione libera. Fallback settore reso completo (28/28, corretto il buco immobiliari) e indurito (word-boundary, guardie anti-drift). Production-ready, dietro l'interruttore VITE_ONBOARDING_V2.

→ dove si espande: Accenderla (flag + redeploy) e misurare il tempo al primo valore (da 8-10 min a 3).

Per chi non trova il settore in lista, l'AI capisce l'azienda da una frase e prepara il cruscotto.

Un solo onboarding accende il Multiverbe AI; poi ogni pianeta si accende da se alla prima apertura (scheda 'Accendi il Pianeta X'), solo quelli che servono, nel proprio tier e solo per il titolare. Un onboarding per tutti gli abbonamenti.

→ dove si espande: Applicare la migration per accenderlo; la config profonda di ogni pianeta vive nei suoi satelliti.

I servizi dietro prenotazioni, contenuti, vendite, AI, sito, pagamenti. Con buone pratiche (anti-duplicazione, limiti di frequenza, protezione dati personali) e test. 06-06 (#310): aggiunto il typecheck di api/ in CI (prima Vercel compilava con esbuild = tipi ignorati, nessun gate) + bonificati 14 errori-tipo latenti (Stripe, Buffer, sector-reminder, ecc.); resta escluso il cluster WIP site-builder+pipeline AI (tracciato).

I processi pianificati che fanno girare il cervello ogni mattina e tengono aggiornata la memoria. Durevoli: se qualcosa va storto, riprendono.

Incasso reale attivo dal 19 maggio (chiave live, 9 prezzi). Si puo incassare appena c'e l'entita per fatturare.

Instrada le richieste AI verso fornitori europei (Vertex EU Imagen+Gemini, Mistral FR) e si blocca (503 sovereign_routing_required) se nessuno e disponibile, per tenere i dati in Europa. 2026-06-22: env Vertex EU CONFERMATE su Production via Vercel CLI (GCP_VERTEX_PROJECT, GCP_VERTEX_LOCATION, GCP_SA_CLIENT_EMAIL, GCP_SA_PRIVATE_KEY) -> il gateway e PROVISIONATO; nomi env del gateway (google-auth.ts) allineati a quelli impostati. Stage 4 del Site Builder ora passa di qui per le immagini (PR #401). Resta lo smoke test di una generazione reale dietro auth (founder/sessione loggata) prima di vendere la promessa.

RENDER LIVE VERIFICATO 2026-06-05 sera (8 famiglie su trattoria-bellinzona-demo, browser reale). Motore 6 fasi reale (Brand->ArtDirector->Copy->Visual->CRO->Reviewer, multi-pagina+4 lingue, cost-cap, checkpoint). GO-LIVE 2026-06-05 (sessione autonoma): costituzione restaurant APPLICATA e attiva in prod + sito demo ristorante seedato (8 famiglie, 4 lingue, published, business). Trovato e risolto ALLA RADICE il vero blocco: le RLS non esponevano i siti pubblicati ad anon, ogni sito generato dava 404 (PR #240: 6 policy public-read status published + runtime su anon key + fix schema-drift). Verificato verde DB/RLS/REST-anon/middleware/routing. Section library sector-neutral avviata: services-pricing (#244) + faq con schema.org FAQPage (#248) MERGED. 2026-06-06 qualita runtime siti-cliente: SiteHeader (#295), watermark 'Powered by Multiverbe' tier-gated + logo brand con press Apple (#307), CTA hero mobile non copre piu il footer (#311), footer+sezioni page-locale-aware it/de/fr/en (#321); logo SVG ufficiale = task aperto. 2026-06-22: Stage 4 immagini AI NON piu stub - i 4 client lanciavano 'not yet implemented', ora la generazione passa dal gateway sovrano Imagen 4 su Vertex EU (PR #401, dependency injection), i siti generati avranno hero/sfondi/brand AI reali invece di placeholder; e2e completo sito->immagini gated dall'avvio pipeline (QStash, founder). 2026-06-22 (PR #409): 2a costituzione gold-standard = parrucchiere (hair-salon) - HairSalon schema, 4 mood, 13 pageRecipes, 11 sezioni enriched, before/after+portfolio come driver di fiducia; seed migration 2026-06-22d GATED. 2026-06-23 (PR #412/#414/#416/#418): aggiunte le costituzioni gym (ExerciseGym), studi professionali (ProfessionalService, copre 4 sector_id), estetica (BeautySalon) e agenzia immobiliare (RealEstateAgent, la piu ricca: doppio pubblico venditore+compratore, schema a due nodi RealEstateListing+Accommodation+Offer). Il Site Builder ora copre 6 settori dedicati e TUTTE e 6 le costituzioni sono APPLICATE e ATTIVE in prod (scoperto e risolto che solo restaurant era attivo e hair-salon era uno stub da 46 byte inattivo); i settori senza costituzione dedicata ricadono ancora su 'restaurant'.

→ dove si espande: RENDER LIVE FATTO 2026-06-05: il blocco erano gli env Vercel (NEXT_PUBLIC_SUPABASE_URL + anon key) di multiverbe-sites puntati al progetto Supabase SBAGLIATO (iouqemthcpccyyfhcrno), corretti a yqhixdqipojvgzfadufo + redeploy no-cache. Poi P1 restante (testimonials/team/booking adattivo) + P2 costituzioni restanti (gym/studio/estetica/hotel) + P3 onboarding scoping. Ref: ops/pianeta-web-golive-verify-2026-06-05.md.

Il vecchio motore su Render. Eliminato (niente piu Python, niente Render). Demolizione completata.

Vecchio strato mai messo in produzione, superato da Vercel + Inngest. Da rimuovere dal codice.

Il database vero del prodotto (rif. yqhixdqipojvgzfadufo, Germania). Oltre 100 tabelle con isolamento per cliente e dati reali. Avvisi di sicurezza ridotti a 2; protezione password-trafugate accesa.

Cerca i ricordi per significato. VERIFICATO 2026-06-22 (env reale Vercel via CLI): VOYAGE_API_KEY presente su Production, quindi gli embedding sono attivi (non piu versione ridotta). Allineato al floor brain-memory (92%).

I parametri di riferimento per settore che il cervello usa per capire se un numero e buono (es. tasso di cancellazione tipico). ~30 voci caricate.

RISOLTO 2026-06-04: il vecchio database gemello (rif. iouqemthcpccyyfhcrno, Irlanda) e stato ELIMINATO dal Dashboard Supabase dopo inventario (era pieno di lead italiani gia bruciati, una passivita GDPR, non un asset). Lo strumento Supabase vero e gia puntato al progetto di produzione (yqhixdqipojvgzfadufo, eu-central-1). Restano solo igiene a bassa urgenza lato founder: revocare 3 grant OAuth ai provider e disconnettere il connettore MCP stale via /mcp.

Wildcard *.multiverbe.app attaccato al Vercel multiverbe-sites. 2026-06-05: PRIMO sito pubblicato (demo trattoria-bellinzona-demo) RENDERIZZA LIVE (8 famiglie, verificato browser reale). Middleware host->subdomain + routing verde. Il 404 aveva DUE cause: (1) RLS senza lettura pubblica dei pubblicati -> risolto PR #240; (2) gli env Vercel (URL+anon) puntavano al progetto Supabase SBAGLIATO (iouqem invece di yqhix) -> corretti + redeploy no-cache.

→ dove si espande: Demo live OK. Resta: giro a11y/mobile/i18n/schema.org/perf su sito reale + igiene env (scope Development URL e SUPABASE_SERVICE_ROLE_KEY ancora su iouqem, da riallineare a yqhix).

Buona postura: regole su cosa il sito puo caricare, protezioni varie, scansioni automatiche che bloccano le falle prima del rilascio.

L'app e chiusa al pubblico: entra solo chi e in lista. Iscrizione libera bloccata fino al 20 giugno; il gate del 10 si chiude con inviti diretti.

Da fine giugno si entra con Face ID, impronta o Windows Hello (le 'passkey', lo standard WebAuthn supportato nativamente da Supabase) come metodo PRIMARIO, accanto a email piu password, magic-link, Google e Apple. Il dato biometrico non lascia mai il dispositivo: al nostro server arriva solo una chiave pubblica, quindi non esiste il rischio di rubare impronte dal database. Chi perde il telefono rientra con i codici di recupero monouso (lo stesso meccanismo di Google e GitHub), mostrati una sola volta all'attivazione e custoditi solo come impronta cifrata e 'pepata' (il segreto del pepe sta nelle variabili d'ambiente di Vercel, mai nel database). Stato: la PR Multiverbe#425 e stata mergiata e messa in produzione il 24 giugno 2026; la migration e applicata in prod, le passkey sono abilitate sul cruscotto Supabase e il segreto RECOVERY_CODE_PEPPER e impostato su Vercel. Manca solo la prova finale su un telefono reale.

L'obiettivo del gate. Siamo a 0 su 5. Il piano in costruzione piu importante di tutti.

→ dove si espande: Catena Loris: contatto a freddo, demo, chiusura. Il prodotto e pronto a supportare la demo.

Senza l'entita legale non si possono emettere fatture, e questo blocca anche la verifica di Meta Business. Serve il deposito notarile (capitale CHF 20k) e i documenti societari.

→ dove si espande: Completare la costituzione: sblocca incasso legale e verifica Meta.

Strumenti di vendita in avvio: Apollo, riscaldamento caselle email (Lemwarm), ricerca salvata su Lugano.

→ dove si espande: Portare a regime la cadenza di contatto giornaliera.

Free, Starter Light, Starter Full, Pro, Business, con prova 10 giorni senza carta e garanzia 30 giorni. In sospeso dal 21 maggio una revisione del listino (Finanza, tetto WhatsApp, Documenti e Firma).

→ dove si espande: Chiudere la revisione del listino in sospeso.

La leva di vendita killer: 10 giorni di funzioni Pro complete senza carta. Attiva.

Le pagine pubbliche sono online e sane, con la voce del marchio e il banner cookie a norma. 2026-06-22: Microsoft Clarity ATTIVO sulla landing (progetto xazmjo2s89, env su Vercel, deploy live verificato, consent-gated). Ogni sito-cliente generato auto-inietta Clarity consent-gated quando il titolare collega il suo progetto (sites-runtime ClarityScript). Restano lato founder: collegare il token Data Export in app (porta i dati nel Sole) + aggiungere Clarity a privacy/subprocessors + togliere il tag Clarity da GTM (anti doppio-load). Miniguida: ops/guida-attivazione-connettori.md.

Portfolio dedicato pronto a sponsorizzare. WhatsApp Business bloccato sulla verifica, che dipende dai documenti dell'entita svizzera. 2026-06-22 (verifica browser): Business Suite Multiverbe attivo (Pagina FB + profilo Instagram, 0 follower, appena creati) ma NESSUNA app sviluppatore con permessi Instagram approvati (App Review non avviata, gated dall'entita). Permessi Instagram NON concessi.

→ dove si espande: Sbloccare WhatsApp/Instagram completando l'entita + App Review.

APPROVATO da Google il 2026-06-18 ('approved to use the Google Business Profile API'). 2026-06-22: il connettore Google one-consent (GA4+GSC+GBP, #335/#381) e ora ENV-COMPLETO su Production: GOOGLE_OAUTH_CLIENT_ID/SECRET/REDIRECT_URI gia impostati, e questa sessione ha aggiunto la chiave madre dei connettori OAUTH_TOKEN_ENCRYPTION_KEY + OAUTH_STATE_SECRET e i flag GOOGLE_SEARCH_CONSOLE_ENABLED=true + GOOGLE_BUSINESS_PROFILE_ENABLED=true. Search Console: multiverbe.com gia verificata. Connettore PRONTO: resta solo il gesto 'Login con Google' in-app (founder) per salvare il token cifrato e leggere i dati.

→ dove si espande: Founder: 'Login con Google' in-app per attivare GA4+GSC+GBP end-to-end; poi verifica che la pagina Analytics si popoli.

Da creare l'account corretto multiverbe.ch: attivita aperta segnata come critica.

→ dove si espande: Creare l'account e impostare le prime campagne.

Il documento operativo condiviso, vivo su bos.multiverbe.com. Un solo progetto Vercel collegato (niente piu corse di rilascio). Maturo.

La revisione olistica di qualita del codice e in ritardo di circa due settimane (ultima il 19 maggio). Va rilanciata: lo standard e quello di un SaaS di altissimo livello.

→ dove si espande: Eseguire /quality-check e rimettere la cadenza in pari.

Due alberi di documenti paralleli (canon/ e source/) si contendono il ruolo di verita ufficiale e rischiano di divergere. Va dichiarato quale comanda.

→ dove si espande: Scegliere una sola fonte ufficiale e marcare l'altra come derivata.

La mappa vivente dei due grattacieli, con la regola che ogni conversazione/decisione sull'app la aggiorna. In costruzione, versione 2 (schematica).

→ dove si espande: Cancello automatico: l'hook di sessione sorveglia la freschezza; estendere verify per bloccare se va stale.

Protezione dati svizzera ed europea ben presidiata: privacy, banner cookie, lista sub-fornitori versionata, registro consensi.

La mappa vivente (questa, /cantiere) con i due grattacieli, lo schema del cervello e i colli di bottiglia, PIU la mappa del prodotto (/mappa) ora resa enciclopedia completa: schermate front+back, pianeti, cervello, settori e prompt, dove impara, dati, con indice laterale e circa 10 diagrammi.

→ dove si espande: Tenerle aggiornate a ogni decisione (regola Visione Totale).

Completato 2026-06-06 (PR #306). Grafo ristretto al CODICE dell'app (.graphifyignore): code-only ~6.2k nodi, ~11.9k archi, 321 gruppi (prima era regredito a tutto il repo: 9k+ nodi con 3.7k documenti + la libreria vendata supabase-py). Git-hook lo aggiorna a ogni commit (~17x meno token). STRATO SEMANTICO ACCESO: tutti i 321 gruppi hanno un nome leggibile (.graphify_labels.json), prodotti dalla sessione Claude (Anthropic) e preservati dai rebuild. Le sessioni Claude lo interrogano prima di leggere a tappeto. Affiancato da opensrc (sorgente reale delle dipendenze).

→ dove si espande: Opzionali post-gate: lente Obsidian (un comando) + estensione semantica LLM ai documenti; rinominare i gruppi nuovi dopo refactor importanti.

Vista a grafo locale sul tuo computer per esplorare a colpo d'occhio. Non puo vivere sul BOS (app desktop): e la tua lente personale alimentata dallo stesso grafo. Ora SBLOCCATA: il grafo esiste (code-only, etichettato), la lente si genera on-demand.

→ dove si espande: Generare la vault con 'graphify export obsidian' (un comando), quando serve.