Decisioni

Chi: Gregorio (sessione agentica: "collega FINALMENTE le mail nell'app · estrema qualità sul lavoro che devi fare, per le altre idee genera chip · poi chiudiamo" · scelte: motore + UI + Gmail OAuth dormiente · 🔴 azione anche push). Claude (build born-green + PR #578 + 3 chip + memory + questa entry). Segue v254 (audit/tassonomia sorgente).

Costruito → PR #578 (born-green · CI-autoritativo per HDD gridlock · review avversariale 0-issue):

• Catalogazione a 2 assi — il buco reale: le colonne ai_category/ai_priority esistevano dalle fondamenta ma nessuno le scriveva. Ora: FUNZIONE→pianeta (crm/booking/sales/finance/reviews/marketing/system/other) · PRIORITÀ→azione (action/normal/muted). Sector-aware e impara dalle correzioni (category_source='user' mai sovrascritto).
• Classifier via il gateway sovrano EU (dispatchText, PII-gate, Gemini Flash = tier interno economico). Migration in prod (0 advisor). 🔴 azione → notifiche hub (ai_notifications) + push. UI: coda azione in cima, filtri per pianeta, rumore di sistema collassato (il critico non affoga), correzione via RLS. 5 lingue.

🧭 Principio prodotto (founder, PERMANENTE): le notifiche sono come Multiverbe comunica A NOI (proattivo); la chat è come NOI comunichiamo a lui. Multiverbe, quando ha un dubbio o gli servono dati, CHIEDE proattivamente via notifica per lavorare al meglio. Le 🔴 dell'Email Hub sono il primo esempio del pattern.

DA FARE (chip spawnati + questo log):

1. Sito collegato → il Sole legge ed estrae i dati business (email, orari, servizi, team, P.IVA), chiede conferma via notifica, poi popola proattivamente CRM/Content/Booking/caselle-dominio. Chip task_6595000e. È il primo caso concreto del principio sopra.
2. Affinare il prompting interno del Sole (self-model): fargli comprendere com'è costruito lui (6 pianeti + Centro, brain routing 60/30/10, 3 layer memoria, esecutori), cosa può e non può fare, il suo scopo, la sua adattabilità (sector-aware) → comportamento proattivo. Chip task_aaa2eb09.
3. Gmail OAuth 1-clic dormiente (auth sensibile · migration token propria · XOAUTH2+refresh nel sync · verifica Google ~settimane; Gmail già collegabile via IMAP oggi). Chip task_049d4d99.

Restano: merge #578 a CI verde (Charter §9) + verify live (0 caselle in prod → il founder collega una casella reale, dogfooding metaverbe@gmail.com IMAP + noreply@multiverbe.com). Nota collaterale ricordata al founder: 🔴 pagamenti falliti carta …9808 (Supabase pending-shutdown / Anthropic / Iubenda) = azione founder.

Numerazione v256: rinumera al push se già presa (v255 = temi design, sessione parallela).

---

Chi: Gregorio (post-#573 vetro: "voglio vedere la mia app come un ambiente modificabile con template di ALTISSIMA gamma predisposti per Multiverbe — spaziatura, rotondità pulsanti, ecc., restando nello stile minimal · siamo un'azienda che vuole attrarre miliardi → prodotto pazzesco · genera un chip continuativo E migliorativo"). Claude (preview interattiva + chip + memory + questa entry).

Cosa:

• Preview consegnata (Artifact df3f37e5, "Ambiente di design Multiverbe"): le superfici reali dell'app (card pianeta KPI+pillole · card satellite · navbar sfera+pianetini · testata pannello) in vetro liquido, con 4 template commutabili (Osservatorio default · Nebula Compact denso · Aurora Soft morbido/pill · Mono Editorial netto) + slider dal vivo Rotondità/Spazio/Vetro. Concetto: un template = un set di design-token applicati a TUTTE le superfici da un punto solo.
• Chip task_7db57ff2 "Sistema temi Multiverbe" (continuativo #573 + migliorativo): estrarre i valori vetro/spazio/rotondità del #573 in design-token CSS, 3-4 preset nominati, switcher in Impostazioni persistito per-workspace (multi-tenant · RLS se DB), applicati a tutte le superfici. Default = Osservatorio → zero regressione.
• Regola confermata: ogni chip continuativo con la direzione data E sempre migliorativo (best-practice/tecnologie 2026).

Come: preview standalone (CSS reale del #573, font system-ui) + chip agentico + memory project_design_environment_theme_system_2026_07_10.

Restano: build feature via chip task_7db57ff2 (born-green · cost-mode · worktree isolato · ⚠️ sessioni parallele). Se serve migration (tema per-workspace) → chiedi founder.

Numerazione v255: rinumera al push se un'altra sessione ha già preso v255 (v254 = email cataloguing, sessione parallela · consolidata qui).

---

Chi: Gregorio ("voglio che le mie mail Multiverbe come quelle degli utenti vivano tutte nell'app catalogate in modo ordinato · vicini alla produzione · collega FINALMENTE le mail Multiverbe nell'app · task grossa → genera un chip agentico coordinato · chiudiamo"). Claude (audit Gmail via MCP + 2 ricerche web + tassonomia + memory + chip task_e0b6572b + questa entry).

Cosa:

• Audit Gmail founder reale (metaverbe@gmail.com): 0 etichette (inbox non organizzata); ~70% notifiche automatiche dev (GitHub/Vercel/Google); 🔴 pagamenti falliti sepolti UNREAD — Supabase "Pending Shutdown" ($25, carta …9808, prod DB a rischio), Anthropic €219.60, Iubenda (.app+.com) → carta …9808 rifiutata su più servizi = azione founder urgente. = la pain esatta che l'Email Hub risolve.
• Ricerca web PMI: label>folder; categorie funzionali; max 3-5, profondità ≤3; retrieve-based; automazione filtri; auto-classificazione a regole debole → l'AI Sole è il differenziatore.
• Tassonomia Multiverbe (moat) — 2 assi: FUNZIONE=Pianeta (Clienti→CRM · Prenotazioni→Booking · Lead→Sales · Fornitori&Fatture→Finance · Recensioni→satellite · Marketing · Sistema→muted) × PRIORITÀ (🔴 Azione/Scadenze in cima). Sector-aware (settore onboarding = default categorie). Classificate dall'AI Sole + pseudonimizzazione pre-Anthropic.
• Chip agentico coordinato spawnato (task_e0b6572b): costruire l'Email Hub cataloguing estendendo PR1/PR2 + feat/domain-email-hub/#575 + OAuth Google + CRM link; connette SIA mailbox founder (dogfooding) SIA utenti.

Come: Gmail MCP (list_labels + search_threads filtrata anti-rumore) + 2 WebSearch + sintesi. Non mutata la Gmail (nessuna label applicata — solo analisi). Memory project_email_hub_cataloguing_2026_07_10.

Restano: 🔴 founder: aggiornare carta pagamenti (…9808) — Supabase/Anthropic/Iubenda (rischio shutdown prod). Build via chip (born-green, cost-mode, 5 lingue, workspace_id isolation/RLS, plan-first).

Numerazione v254: rinumera al push se un'altra sessione ha già preso v254.

Chi: Gregorio (chip estrema-qualità "i18n EN→IT pannelli Web", poi "chiudi in autonomia + mergia"). Claude (diagnosi premise-drift + fix + SoleNextMove 5 lingue + born-green + squash-merge + questa entry + memory project_web_panels_i18n_flash_fix_2026_07_10).

Cosa — PR #572 squash-merged in master@10123b8 (4 file, born-green 2653 test):

• Premise drift: il chip supponeva "stringhe inglesi hard-coded". In realtà il catalogo cockpit-i18n.ts era GIÀ completo in 5 lingue (it/de/fr/en/es). Il bug era la RISOLUZIONE della lingua, non il testo.
• Causa reale: la cabina "I miei siti" ripiegava su ?? 'en' mentre attendeva GET /api/web-hub/sites (serverless, cold-start di secondi), con la chrome react-i18next già IT sincrona → flash inglese al carico fresco (il "42 EN vs 6 IT" del QA founder). DB prod: tutti i workspace hanno primary_language='it' → era solo il fallback in attesa della rete, non un dato sbagliato.
• Fix: sites.data?.locale ?? getLanguage() — il fallback è la lingua dell'interfaccia (it/de, mai 'en'), sincrona → schede nella lingua giusta dal primo frame. + SoleNextMove (card "Prossima mossa dal Sole", ultima chrome solo-IT) localizzata in 5 lingue via catalogo. "Sole" tenuto come nome proprio dell'AI in tutte le lingue (come "Multiverbe").
• Confinato a 4 file, nessun file web-hub conteso (cost-mode + PR web-hub parallele). ⚠️ il merge tocca MySitesPage → #576 (chip #3 sito+dominio) va rebasato su master.

Resta: verify live founder (Web a freddo su multiverbe.app → IT dal primo frame, niente flash). Follow-up minore: campo locale API /sites ora client-inutilizzato (pulizia differita, file contesi).

Owner: Gregorio (decisioni + delega merge) · Claude (diagnosi premise-drift + fix + merge + verifica gate).

---

Chi: Gregorio (chip "estrema qualità big-tech", mockup vetro-glass v2 approvato · direttive: velatura soffusa+omogenea del colore del pianeta con frost per leggibilità · pianeta≠satellite · via il pianetino · Sole in un solo posto · desktop più arioso). Claude (build + born-green + verifica gate + questa entry + memory project_vetro_glass_shell_2026_07_10).

Cosa — PR #573 born-green, mergeable: CLEAN (Batch1 "Shell & Vetro" dell'epic glass/navbar · 8 file, +413/-439):

• Vetro liquido su PlanetPanel/PlanetDashboard/SatelliteCard: via il nero-opaco rgba(9,9,11,.36) → frost scuro (leggibilità) + velatura EVEN del colore pianeta/satellite (color-mix in srgb ~15-20%), non un faro. Il colore risalta, il testo resta leggibile.
• Card PIANETA = riassunto completo (KPI + pillole dei satelliti, desktop 380→620px, più alta/in alto) vs card SATELLITE = solo il suo compito (focalizzata, niente KPI/pillole) → risolve pianeta ≠ satellite.
• Rimosso il pianetino di fianco al titolo (la tinta È l'identità).
• Sole unificato: la sfera centrale della navbar è l'UNICO posto per parlare col Sole → apre la chat v9 col messaggio digitato; rimosso il pill flottante "Parla con Multiverbe" (doppione temporaneo). AI Hub resta raggiungibile (connettori chat + sidebar). Pianetini Impostazioni/Account rifiniti (liquid-glass ciano/verde).
• Quick-win copy: "Hai 1 contenuti" → "1 contenuto" (it+fr).

⚠️ 2 DEVIAZIONI dal literal del chip (scelte motivate, founder conferma):

1. Pianeta Finanza NON rimosso dalla sidebar: è già gated useFinanceEnabled (visibile solo su workspace interno Multiverbe, MAI clienti) → è il 7° pianeta gated deliberato (palette.ts), non legacy MAIND. Rimuoverlo nasconderebbe il tool finanza del founder. Regola "guarda il target prima di cancellare".
2. "Sistema solare più in alto" (camera 3D) deferito: card ingrandita/alzata (DOM, sicuro); il framing verticale è territorio 3D del founder, meglio dal vivo insieme.

Come: worktree isolato mv-vetro-glass da origin/master (b736421, include #569) per non disturbare la sessione parallela fix/pwa-update-flow. Born-green: tsc + typecheck:api + lint(0 err, 527 warn<560) + knip(0) + invarianti(3/3) + depcruise(0) + vite build + 2653 test verdi. Prima/dopo (CSS reale): Artifact 912e31f0.

Restano (founder): verifica live dietro login + merge #573 (dashboard auth-gated, non raggiungibile headless: controlla tint=colore reale pianeta, card piena superficie, sfera navbar→chat, no pill flottante) · confermare le 2 deviazioni · camera "più in alto" + eventuale cap pillole satelliti su mobile (da tarare live). Follow-up chip task_1a9a466e: pluralizzazione SISTEMICA it/fr insight (qui fixato solo contentBody).

Numerazione v252: rinumera al push se un'altra sessione ha già preso v252 (v251 = #570 cervello EU, sessione parallela).

---

Chi: Gregorio (get-ahead sovranità EU · "apri le schede, io accedo, aiutami fino a dove puoi +1" · decisioni: Sonnet 5 come sonnet-hop · niente fallback "o EU o niente"). Claude (verifica codice LIVE + QA dal vivo GCP Console browser-guidato + questa entry + memory project_brain_eu_vertex_multiregion_2026_07_09).

Cosa:

• #570 (era deferita da v249) ora registrata: master@b736421 born-green — aggiunge (1) l'endpoint Vertex EU multi-region (aiplatform.eu.rep.googleapis.com + /locations/eu, richiesto da Opus 4.8 offerto SOLO multi-region) e (2) GCP_VERTEX_CLAUDE_LOCATION dedicata al cervello per non spostare Gemini (resta su GCP_VERTEX_LOCATION). Completa #512 (cervello dietro flag BRAIN_EU_VERTEX, dormiente OFF).
• Sonnet 5: il sonnet-hop va a claude-sonnet-5 (GA su Vertex, id confermato dal vivo) non il default codice claude-sonnet-4-6 → serve pin GCP_VERTEX_CLAUDE_MODEL=claude-sonnet-5. (Canon/CLAUDE.md dicono ancora "Sonnet 4.6" → follow-up.)
• Niente fallback runtime (o EU o niente): un errore Vertex fa errare il Sole finché non si toglie il flag; il "loud failure" allo smoke-test è la verifica di genuinità.
• 🔴 SCOPERTA (QA GCP dal vivo): l'attivazione è bloccata da un gate ELIGIBILITY Google, non da config. Progetto multiverbe-2606030125: tutte le famiglie Claude hanno quota 0 (EU/Global/US multi-region); 6 richieste di aumento EU già inviate 1-2 lug → tutte NEGATE (auto-diniego, NOT_ENOUGH_USAGE_HISTORY = dual-gating maturità billing + storico uso Vertex + risk third-party Anthropic). Self-serve esaurito. Nessun gate "enable/accetta termini" per-modello (prereq già soddisfatti; Gemini gira). Percorso reale: (a) storico uso Vertex — Gemini già in prod aiuta; (b) support ticket "Vertex AI → Model access" = revisione manuale, unico canale che sblocca da 0; (c) escalation account-team GCP.
• Impatto pitch 13/7: revisione manuale = giorni/settimane → EU genuino NON attivabile in tempo. Il Sole resta US-diretto pseudonimizzato (compliant revFADP/GDPR). ⚠️ Non rivendicare "AI sovrana EU live"; claim onesto = "architettata + shippata a codice, in abilitazione con Google".

Come: verifica codice a b736421 (origin/master = LIVE prod) + QA dal vivo GCP Console (browser guidato, founder loggato): Model Garden (Sonnet 5 GA, nessun enable-gate) + Quote (tutte 0) + tab Richieste-di-aumento (6 negate 1-2 lug). Re-inviato oggi un retry-test con giustificazione forte (uso prod + residenza-dati EU + storico Gemini) come sonda eligibility. Web (google.dev forums) conferma pattern + percorso.

Restano (founder): esito retry-test (Approvata → altre 8 quote EU + Vercel env GCP_VERTEX_CLAUDE_LOCATION=eu+BRAIN_EU_VERTEX=1+pin Sonnet 5 + redeploy + smoke; Negata → support ticket, Claude lo prepara). Follow-up: allineare canon a Sonnet 5; fallback osservabile solo se un domani si vuole accensione rischio-zero (memory lo descrive).

Numerazione v251: rinumera al push se un'altra sessione ha già preso v251.

Chi: Gregorio (chip task_50de3c50 Fase2-Batch2 "flussi": l'email deve "assomigliare all'interfaccia mail classica ma migliorata", universale per l'espansione mondiale). Claude (build + migration + validazione + memory + questa entry).

Cosa: chiuso il gap #1 del founder sull'email. Prima si poteva solo collegare una casella esistente (SMTP/IMAP); ora c'è la guida per avere l'email sul dominio proprio (info@azienda.ch) con record DNS copia-incolla e validazione live per-record.

• Email di dominio: card provider verificati sul web (Infomaniak CH default, Google Workspace, Zoho EU, + Altro/Personalizzato), righe MX/SPF/DKIM/DMARC, stato live via node:dns (match robusto per suffisso), gotcha "pubblicato non basta: clicca Verifica/Enable + attiva DKIM", attesa propagazione, next-step verso la casella.
• Il join che mancava: email_accounts.domain + tabella email_domain_setups (migration applicata a prod, RLS come email_accounts, 0 nuovi advisor).
• Email Hub classico ma migliorato: client 3 pannelli (caselle/cartelle, lista, lettura), drill-down mobile. Universale: 129 stringhe x it/de/fr/en/es via useWorkspace (pattern satellite Recensioni).
• Consolida i mai-mergiati PR1+PR2 Email Hub su origin/master.

Come: branch feat/domain-email-hub (63e672d), NON pushato (cost-mode: founder pusha/mergia, 1 PR squash). Born-green CI-autoritativo: HDD in gridlock (34 processi sullo store) blocca tsc/build/lint/knip in locale, come PR1/PR2 -> CI Linux = gate autoritativo alla push. Validati in locale: logica DNS 17/17 (anche contro DNS reale), i18n 129x5, lockfile CI-valido, INV-3 ok, migration verificata in prod.

Restano (founder): push + PR + CI verde + squash-merge; verify live UI post-deploy. Follow-up: Gmail/Outlook OAuth 1-clic, PR3 thread<->CRM, PR4 rispondi/invia, piu provider (M365/Aruba/Register.it).

Numerazione v250: rinumera al push se un'altra sessione ha gia preso v250. NB: la entry v249 (chip glass-navbar, altra sessione) era gia non committata in questo file al commit -> inclusa qui.

Chi: Gregorio ("chip di estrema qualità, esperienza da big-tech"; poi redirect con direttive di design + "genera un chip che lavori a tutto questo, salva, chiudiamo"). Claude (Fase 0 skill + Fase 1 QA dal vivo + mockup + chip task_05d38b85).

• Fase 0 — SKILL creata: ~/.claude/skills/multiverbe-onboarding-domain-ux/ = paved-path per i 3 flussi ad alto attrito (crea/collega sito · dominio DNS/verify/wildcard/Domain-Connect · email di dominio MX/SPF/DKIM/DMARC) + onboarding zero-frizione, distillata dal web 2026 (Vercel/Framer/Netlify/Zoho/Google-Workspace/Shipmail + benchmark onboarding). (CLAUDE.md dice 13 skill → ora 14, follow-up conteggio.)
• Fase 1 — QA dal vivo prod (Chrome MCP, bundle v10 fresco) · findings:
  • Padlock + navbar vuota del founder = cache v9 stale nella PWA iOS, NON prod (fresh v10: navbar #569 ok, lockByClass=0). Root: manca il listener client di SW_UPDATED → una PWA aperta resta sui chunk vecchi finché non fai hard-refresh. → fix = flusso update in-app.
  • DOMINIO = finto-fatto: api/site/custom-domain.ts reale e completo (Vercel) ma zero UI (nessun tab Dominio).
  • Pannelli Web in INGLESE su prodotto IT-first ("My sites / Analyze a site / Turn on stats"): gap i18n dei pannelli external-site-hub.
  • Publish senza next-step · email di dominio senza guida MX/DKIM · vetro panels troppo scuri (PlanetPanel rgba(9,9,11,.36)) e piccoli (PlanetDashboard 5% schermo).
• 🔀 DIRETTIVE FASE 2 (founder, vincolanti) — scelta: opzione 3 (Shell&Vetro poi Flussi, in sequenza, estrema qualità) + mockup-prima (fatto: Artifact vetro-glass):
  1. Sole = un solo posto: pill "Parla con Multiverbe" = bottone Sole centrale → unificare (troppi luoghi).
  2. Card PIANETA ≠ card SATELLITE (concetto chiave): clic pianeta = riassunto completo del pianeta; clic satellite = solo ciò di cui quel satellite si occupa. Separare i due livelli.
  3. Desktop: card pianeta selezionato più lunghe + sistema solare più in alto.
  4. Vetro: sfumatura card = colore del pianeta/satellite selezionato → via il pianetino di fianco al titolo (il colore è l'identità). Apple-cards tonde, liquid glass, eliminare estetica "AI-made slop".
  5. 📌 2D FALLBACK (founder l'ha stressato "importante, nel BOS"): centro 2D = logo Multiverbe · pianeti 2D = forme 2D dei pianeti 3D che il founder ha QUASI completato (suo WIP → NON inventarle) · decadimento a 2D solo se il device non regge la grafica (capability-based, NON reduced-motion) · chi ha buona connessione+hardware = la grafica migliore in assoluto oggi su tutto (3D/2D/testo/ogni componente).
  6. Email (Batch 2): interfaccia mail classica ma migliorata, universale (espansione mondiale).
  7. Qualità massima in ogni minimo dettaglio.
• Mockup vetro v2 premium (Artifact 5836bfb0…): dopo feedback founder ("luce troppo forte, copre le scritte, poco omogenea → poco premium") → velatura soffusa+omogenea, frost per leggibilità testo, orb dim/spostato. = north-star del chip vetro.
• → 6 CHIP spawnati (founder: "genera TUTTI i chip necessari, vicini alla produzione, aggiorna e chiudi") — 1 PR coesa ciascuno, born-green, branch fresco da origin/master (la sessione madre era su chore/web-reviews senza #569), cost-mode:
  1. Fix cache PWA + flusso update in-app (root del padlock/stale) — urgente
  2. Vetro glass full-surface + navbar/Sole unificato (il grosso visivo · card pianeta≠satellite · no pianetino · desktop più lungo/alto)
  3. Flusso sito+dominio (UI su API custom-domain reale + publish next-step)
  4. Email di dominio MX/DKIM + Email Hub (classica-ma-migliore, universale)
  5. i18n EN→IT pannelli Web (coordina con lingue #521/#522/#550)
  6. Grafica adattiva (fallback 2D capability-based + max qualità; le forme 2D/logo-centro = WIP founder, non implementate) Ordine consigliato 1→2→3→(5)→4→6, rebase tra quelli che toccano il pannello Web. Dettaglio: memory project_glass_navbar_flows_epic_2026_07_09.
• Stato chip (10/7, in corso d'opera): ✅ Chip 1 (fix cache PWA + flusso update) FATTO — PR #571 merged (master a4a3804), v11 LIVE prod (verificato curl multiverbe.app/sw.js → multiverbe-v11-update-prompt). ⚠️ La premessa "manca il listener SW_UPDATED" era errata (il listener c'era in main.tsx): root vero = il SW serve gli script cache-first → le PWA installate prendono il codice nuovo solo al bump di CACHE_VERSION, e il vecchio flusso era un reload muto inaffidabile su iOS. Fix = prompt discreto "Nuova versione disponibile · Aggiorna" (pattern vite-plugin-pwa "prompt", best practice 2026 per app con form). Caveat: le PWA v9/v10 già installate atterrano su v11 alla prossima chiusura+riapertura completa (non si inietta codice in un bundle già spedito). Copy it/de wired (5 lingue pronte). Isolato in worktree per contesa multi-sessione. Dettaglio: memory project_pwa_update_flow_2026_07_10. · Chip 2/5/4 risultano con PR born-green da sessioni parallele (#573 vetro glass · #572 i18n pannelli Web · feat/domain-email-hub email) → verify+merge founder.
• Numerazione v249: rinumera al push se un'altra sessione ha già preso v249.

Chi: Gregorio ("in prod non vedo la card, non vedo Impostazioni/Account nella navbar, 'la tua giornata' non doveva esserci, iPhone fisso in 2D, Content dice pronto ma è vuoto — scovali tutti e correggili; il design lo vediamo dopo"). Claude (diagnosi 2 agenti Explore + DB live + implementazione + born-green + PR #569).

• 🎯 5 bug prod diagnosticati alla radice e corretti (born-green: tsc/eslint/knip/invarianti/depcruise/vite build/2646 test):
  1. Pillola "La tua giornata" (stopgap HomeBriefButton, arrivata in #554 prima della card) → rimossa; la card MULTICHAT v9 + "il luogo" la sostituiscono. /home resta solo via URL diretto.
  2. Card Multiverbe invisibile + iPhone fisso in 2D = cache PWA stale: la card è in prod (#557) ma il bundle pre-MULTICHAT in cache mostrava la pillola-non-la-card e (device.ts vecchio) cadeva in 2D con reduced-motion (il founder ce l'ha ON). Fix: bump CACHE_VERSION → v10-multichat-home-nav (il SW auto-invalida → codice nuovo → card visibile + scena sempre 3D salvo hardware incapace). ⚠️ founder post-deploy: chiudere/riaprire la PWA su iPhone (iOS cache aggressiva).
  3. Content "pronto" ma vuoto: il messaggio contava content_generations (ledger costi AI, 1 riga/chiamata) mentre la UI elenca content_items/social_posts. Fix: contentMetrics.generated_* su content_items (SSoT editoriale) + atterraggio automatico sul tab "Calendario" (non il wizard "Crea" vuoto). Booking/CRM/Sales verificati coerenti (nessun mismatch).
• 🔀 DECISIONE NAVBAR (founder, SUPERA le precedenti): la bottom-nav mobile diventa [satellite] · Impostazioni · Sole · Account · [satellite].
  • Impostazioni a sinistra del logo, Account (pianetino) a destra come voci fisse; rimosso il gear flottante top-right (SettingsButton, collideva con la Dynamic Island). Accesso alle Impostazioni solo dalla navbar (desktop: resta in PlanetSidebar). Deep-link alla sezione giusta via nuovo store.settingsScope (business/account). → SUPERA la decisione 2026-05-18 "metti in alto a destra il simbolo delle impostazioni".
  • Ai lati estremi si pinnano SOLO i satelliti, non i pianeti ("i pianeti sono sempre tutti nella home 3D → ridondante pinnarli"). → SUPERA "bar inferiore = pinnable shortcuts (con pianeti ai bordi)". Spariscono pinnedEdgePlanets + tier-gating dalla barra.
  • ⚠️ Rifinitura visiva dei "pianetini" = fase design (founder: "il design lo vediamo dopo"). Funzionale ora, estetica poi.
• Metodo: 2 agenti Explore (content data-flow + navbar decided-spec) + DB live (b781a7b4…: 3 todo oggi, 49 insight content, il "14 contenuti" era stantio) + git (pillola #554 < card #557) + analisi service-worker (nav network-first, asset cache-first → stale = bundle vecchio). Install worktree lento (~35min) ma completato → gate pieni in locale. PR #569, merge a CI verde (autorizzato founder).
• Canon da allineare (follow-up): canon/13-mappa-prodotto.md:357 ("Impostazioni sopra la scena") → riflettere navbar Impostazioni/Account + edges=satellite. Numerazione v248: rinumera al push se un'altra sessione ha già preso v248.

Chi: Gregorio ("landa la #542" → poi "aggiorna il BOS e aspetta la conclusione di un'altra sessione"). Claude (verifica env live + rebase + born-green + merge a verde + deploy prod + questo log).

• ✅ PR #542 MERGED (master@f5d3fa4, squash): gate PII di confine EU (redactPii→redactForExternalBoundary su sole-ask/sector-deduction/memory recall+record/extractor — i nomi propri non attraversano più il confine verso Anthropic-US/Voyage-US) + salt HMAC fail-closed (nuovo helper api/_lib/require-secret.ts, via i fallback letterali ?? 'mv-track-v1'/|| '' su broadcast/unsubscribe/r[slug]/feedback×2/recovery-codes). Terzo e ultimo chip dell'audit 2026-07-03.
• 🔓 Blocco pre-pitch RISOLTO con verifica dal vivo (era HELD perché fail-closed su segreti prod): vercel env ls production → RECOVERY_CODE_PEPPER (Added Jun 24) e MARKETING_TRACK_SALT (dal 6/6) entrambi presenti in Production+Preview → 2FA-recovery + link disiscrizione/feedback/tracking intatti in prod. FEEDBACK_TOKEN_SALT assente ma opzionale (ripiega su MARKETING_TRACK_SALT). Nessun founder-block necessario: verificato direttamente (i file demo-critical sole-ask/memory toccati SOLO per il PII-gate, 0 segreti nuovi → cervello/demo safe).
• Come (Charter born-green · cost-mode 1 CI + 1 build): branch su master vecchio → rebase pulito su master@7669da1 (0 conflitti · merge-tree dry-run + master toccava 0 dei 13 file · types/supabase.ts non toccato dalla PR). Born-green completo nel worktree mv-web-monitored: typecheck:api + lint 0 err + esm/parity/leaks + depcruise + knip + invariants + build (tsc+vite) + 2629 vitest pass (+ 126 test di sicurezza mirati). Push → Frontend CI "Typecheck + build" verde → squash-merge → re-validation su master verde → deploy prod Vercel multiverbe-app success.
• 🎯 Audit 2026-07-03 CHIUSO 3/3: #524 Stripe edge legacy + #537 denial-of-wallet + #542 PII/salt tutti MERGED. Residue aperte pre-pitch: #490/#512 (render Vertex EU · infra GCP_SA_* pronta) + #503 (setup-cli, held). #543/#553 (web-reviews) = consolidamento a parte.
• Decisione founder: BOS aggiornato ora, poi attendere la conclusione di un'altra sessione in corso prima di procedere con #490/#512 e #543/#553 (evita worktree-clobber / overlap — cfr. lezione v246).

Chi: Gregorio ("chiudo con qualità migliorativa, aggiorna tutto e chiudi"). Claude (migliorativa + chip + questo log).

• ✅ Migliorativa dependabot done → PR #560 MERGED, master@b6e3f29: il gruppo dev-tooling ora filtra update-types: [minor, patch] → i MAJOR arrivano come PR singole reviewable invece che in bundle breaking (era la causa di #541). Aggiunto anche .github/dependabot.yml ai path di frontend-ci (pattern #513) così le PR di sola-config sono mergiabili.
• ⚠️ Lezione (worktree-clobber tra sessioni): mentre lavoravo la #560 in mv-web-monitored, una sessione-chip l'ha checkoutato per la sua PR (il mio prompt-chip suggeriva quel worktree) → ha clobberato il mio working tree. Nessun danno perché avevo committato+pushato PRIMA del clobber (la PR su origin era già completa). Regola confermata: committa+pusha presto; e i prompt-chip NON dovrebbero nominare un worktree specifico condiviso. [[feedback_shared_worktree_branch_check]]
• 🎯 STATO FINALE sessione: da 16 → 4 PR aperte (13 risolte: 9 web-hub + #502/#504 dependabot + #559 fix-CI + #560 migliorativa; #541 chiusa; #503 held). Master b6e3f29 pienamente verde (Frontend CI + Planet System CI). 4 residue: #490/#512 (Vertex EU) + #542 (PII) → 2 chip in esecuzione (task_2482fd61, task_732827ce); #503 (setup-cli) held decisione founder. Alla chiusura dei 2 chip resta aperta solo #503 → consolidamento di fatto completo.

Chi: Gregorio ("continua"). Claude (diagnosi + fix + born-green + merge a verde + questo log).

• ✅ RIPARATO il check "Planet System CI" rosso su master (il finding di v244, non-required ma sgradevole a 4gg dal pitch) → PR #559 MERGED, master@7669da1, Planet System CI = success (verificato). Chip task_8561dcbe dismesso (fatto in-sessione).
• Causa: il root pnpm test:coverage globba tutti i test del monorepo con resolve flat senza alias; dal blog engine #546 i file lib di sites-runtime importano via l'alias Next.js @/ → 3 test file fallivano ("cannot find package @/lib/..."). Prod/siti intatti (Next.js risolve @/ in build).
• Fix (born-green): resolve.alias @/ → sites-runtime/ nel vitest.config.ts root. Sicuro: i test frontend non toccano mai @/ nella catena d'import, i packages usano @multiverbe/* → l'alias colpisce solo sites-runtime. Scartato test.projects (vitest 3.2): corretto ma qui rompeva il resolve dei workspace package. Verifica: build packages + pnpm test:coverage → 244 file / 2821 test PASS, 0 failed (locale) → confermato su master (success).
• 2 gotcha CI risolti in corsa: (1) Planet System CI + Frontend CI sono path-filtrati → un cambio al solo root vitest.config.ts non li triggerava (né validava, né sbloccava il required "Typecheck+build") → aggiunto vitest.config.ts + il path del workflow ai trigger di planet-system-ci (Frontend CI ha già .github/workflows/** per lo stesso motivo, cfr. #513); (2) commitlint subject-case (lower/sentence) bocciava i subject con maiuscole → merge squash con subject lowercase conforme → commitlint verde su master.
• Migliorativa v244 ancora aperta: riconfigurare il gruppo dependabot dev-tooling (update-types: minor,patch) per non ri-generare bundle di major come #541.

Chi: Gregorio (menu decisionale a fine consolidamento: "mergia #502/#504, hold #503, chiudo #541" · "#490/#512 chip a fine sessione, salva ovunque, chiudiamo" · #542 "procedi in autonomia"). Claude (esecuzione + verifica CI + chip + questo log). Numerazione: v244 su main a v243; rinumera al push se anticipata.

• Dependabot risolte (decisione founder): #502 checkout v6→v7 + #504 upload-artifact v4→v7 MERGIATE — verificate SAFE post-merge (Frontend CI/"Typecheck+build" verde su entrambi i commit master 92c78c7/8b7fe4a; nessun fail nuovo introdotto). #503 setup-cli v1→v3 HELD post-pitch (rischio workflow supabase, commento sul PR). #541 dev-tooling group CHIUSA — non un colpevole singolo ma bundle di ~15 major breaking (tailwindcss 3→4 che contraddice la scelta v3 dell'app, ts 5→6, vite 6→8, vitest 3→4, eslint 9→10); follow-up: riconfigurare il gruppo dev-tooling in .github/dependabot.yml con update-types: minor,patch così i major arrivano separati e valutabili.
• 🔎 FINDING (non mio, pre-esistente): il check "Planet System CI · L1 vitest + coverage" è ROSSO su master da 8/7 mattina (prima del mio lavoro). Causa esatta: il root vitest run --coverage non risolve gli alias @/lib/* di 3 test file di sites-runtime (brand-dna/section-family/site-url), introdotti dal blog engine #546. NON è il required (Frontend CI è verde → prod/siti/demo INTATTI: Next.js risolve @/ in build), ma è un check rosso da riparare (alias vitest root per sites-runtime, o isolare lo scope). → chip task_8561dcbe.
• 🔴 3 code founder-gated → CHIP (parte autonoma esaurita, sessione chiusa su richiesta founder): #542 PII+salt (task_732827ce: conferma RECOVERY_CODE_PEPPER in prod → rebase+born-green+merge · MARKETING_TRACK_SALT già ok · sole-ask/memory NON aggiungono segreti → demo safe) · #490/#512 Vertex EU (task_2482fd61: infra GCP_SA_* pronta, resta verifica funzionale render/brain EU reale → merge) · Planet System CI (task_8561dcbe).
• 📊 BILANCIO SESSIONE: da 16 PR aperte → 4 aperte (#490/#503/#512/#542, tutte gated/held). 11 PR chiuse: 9 web-hub landate born-green (2 squash #527+#498) + #502/#504 dependabot mergiate; #541 chiusa; #503 held. Master verde sul required (8b7fe4a), 1 check non-required rosso pre-esistente (chip). Migration alert_min_drop a prod + types rigenerati. Branch remote subsumed ripulite.

Chi: Gregorio (sessione dedicata consolidamento, cont. di v241). Claude (rebase --onto + riconciliazione conflitti a mano + migration a prod + born-green + merge a CI verde + questo log). Numerazione: v243 su main a v242; rinumera al push se anticipata (append-only).

• ✅ WEB-HUB CHAIN INTERA LANDATA (9 PR, era DEFERITA in v241 come "entangled"). La misura reale ha smontato la paura: i file condivisi che i commit nuovi toccano avevano churn ZERO da master rispetto al boundary → il rebase --onto è quasi conflict-free. Due merge squash cost-efficient (1 CI + 1 build ciascuno invece di 9):
  • #527 "External Site Hub cockpit v2" — collassa la catena lineare #493+#496+#501+#510+#519+#527 (siti monitorati come entità + pixel analytics/connect + gestione siti + mappa clic). Rebase --onto master a6ac9c0 = replay dei soli 6 commit genuini (i predecessori Site Hub Fase1-5 già in prod), 0 conflitti. Born-green: tsc 0 · knip 0 · invariants ✓ · eslint 0 err · 117 test · build ✓. master@3852483.
  • #498 "External Site Hub STREAM 2" — collassa #498+#509+#518 (avvisi di degrado + soglia per-sito + digest settimanale). Riconciliazione a mano di 14 blocchi (chain A aveva aggiunto integrationId/pixel, #509 aggiunge alertMinDrop/soglia agli stessi oggetti → "tieni entrambe le feature"; fallback UNDEFINED_COLUMN reso robusto preservando integration_id). Born-green: tsc 0 · 152 test · build ✓. master@3d61e57.
  • Le 7 PR intermedie (#493/496/501/510/519 · #509/518) chiuse come subsumed (feature in prod, non abbandonate).
• 🗄️ Migration a prod (feedback "applica additive a prod"): monitored_sites.alert_min_drop (int NOT NULL DEFAULT 8, CHECK 3..50, idempotente) applicata via MCP a yqhixdqipojvgzfadufo · advisor 0 nuovi finding · types/supabase.ts rigenerato (diff = solo 3 righe alert_min_drop) e committato → schema-drift gate verde. monitored_sites base già era in prod da v241.
• 🔴 7 PR RESIDUE, TUTTE founder-gated (parte autonoma esaurita):
  • #542 (PII confine EU + salt HMAC fail-closed): oltre a MARKETING_TRACK_SALT (già settato per v242), richiede RECOVERY_CODE_PEPPER fail-closed (recovery 2FA). I file demo-critical (sole-ask/memory) sono toccati per la PII-gate, non aggiungono segreti → cervello/demo non rischia. Azione: confermare che RECOVERY_CODE_PEPPER è in prod → poi rebase+merge (io).
  • #490 render headless EU + #512 cervello Claude-Vertex EU: infra GCP_SA_* già settata (v242) → resta la verifica funzionale reale (un render / una chiamata brain EU) prima del merge.
  • #502 checkout v7 · #503 setup-cli v3 · #504 upload-artifact v7 (dependabot MAJOR action): required "Typecheck+build" verde, ma rischio di rompere ALTRI workflow dopo il merge a master (#503 setup-cli il più rischioso per i workflow supabase). Rec: HOLD post-pitch (stabilità infra a 5gg dal pitch).
  • #541 dev-tooling group: NON un colpevole singolo — bundle di ~15 major breaking insieme (tailwindcss 3→4 che contraddice la scelta v3 del CLAUDE.md, typescript 5→6, vite 6→8, vitest 3→4, eslint 9→10). Migrazione multi-ora fuori scope. Rec: CHIUDERE + splittare il gruppo dependabot per isolare i major (decisione tooling founder).

Chi: Gregorio ("apri pagine, entra ecc, chiedimi login quando servono l'unica cosa che non fai... procedi in fretta"). Claude (browser reale via claude-in-chrome, verifica dashboard Vercel campo per campo + 2 env settati + redeploy + questo log). Numerazione: v242 su main a v241; rinumera al push se anticipata (append-only).

• 🔧 2 env SETTATI in Vercel prod multiverbe-app Production (browser reale, valori non-segreti quindi digitati direttamente): GCP_VERTEX_GEMINI_MODEL=gemini-2.5-flash (nuovo, fixa il 404 Content Studio) · VITE_ONBOARDING_V2 (esisteva, riscritto a true per certezza — Vercel non rivela mai il valore di una var "Sensitive" già salvata, quindi l'unico modo per essere certi era sovrascriverla).
• ⚠️ CORREZIONE IMPORTANTE: la nota di v241 "manca MARKETING_TRACK_SALT, rompe l'invito-recensione" era basata solo su grep del codice, non sul dashboard reale → SBAGLIATA. Verifica live (ricerca per-nome nel dashboard Vercel, la lista default mostra solo poche righe): MARKETING_TRACK_SALT esiste già dal 6 giugno (Production+Preview) → #542 potrebbe essere già mergeable. Stesso discorso per GCP_SA_CLIENT_EMAIL/GCP_SA_PRIVATE_KEY (Vertex EU, dal 3 giugno) → #490/#512 più vicine allo sblocco. ANTHROPIC_API_KEY/BREVO_*/INNGEST_* tutti già presenti. Lezione: mai dare un env per assente solo dal grep del codice — verificare SEMPRE il dashboard live.
• 🟡 Unico gap reale confermato: PSI_API_KEY (loop visual-QA perfezione, NON demo-critical — il PageSpeed dell'audit web-hub usa GOOGLE_PAGESPEED_API_KEY già settato). Founder ha dato la chiave in chat → NON digitata da Claude (regola dura: mai API key/token in un campo web, nemmeno con autorizzazione esplicita) → campo Key=PSI_API_KEY/Production preparato nel form Vercel, valore da incollare dal founder quando vuole. ⚠️ chiave esposta in chat → da scopare a solo PageSpeed API in GCP console o ruotare.
• Redeploy Production lanciato (deployment Ba18duUNw, master@3852483) subito dopo i fix — in coda/building al momento del log (probabile contesa con i deploy della sessione-chip in parallelo), non ancora verificato l'esito finale.
• Sessione-chip consolidamento (task_25388cd2) in corso IN PARALLELO: dalle 16 PR aperte di fine v241, ora 10 aperte — ha già mergiato l'intera sotto-catena web-hub #493+#496+#501+#510+#519+#527 (squash unico "External Site Hub cockpit v2", tecnica --onto documentata in v241, verifica locale born-green: tsc 0 · knip 0 · invariants ok · eslint 0 err · 117 test web-hub pass · vite build ok). Restano aperte: #490, #498→#509/#518 (secondo ramo web-hub), #502/#503/#504/#541 (dependabot), #512, #542. Claude NON ha toccato queste PR (di competenza della sessione-chip, rischio collisione worktree condivisa).

Chi: Gregorio (chip task_f7ce42f8: "Consolida 26 PR arretrate in prod + setup env Vercel · lavora a lungo con qualità estrema"). Claude (rebase su master + riconciliazione + verifica locale born-green + merge a CI verde + questo log). Numerazione: v241 su main a v240; rinumera al push se anticipata (append-only).

• ✅ 6 PR LANDATE born-green (rebase su master, verifica locale tsc+knip+lint+invariants+build+test, merge solo a Typecheck + build verde):
  • #550 lingue operative workspace end-to-end (Task B Fasi 0-3) — subsume #539/#547/#548 (retarget leaf→master + squash unico). Conflitto import MarketingNewsletter risolto (union useDashboardStore+LanguagePicker).
  • #522 site-builder live+reveal i18n (it/de) — rebase droppa il commit già-in-master di #521.
  • #520 Brand Studio S4 (veloce+su-misura+AI sovrana EU) — subsume #499. Riconciliazione vera: --onto master <S3-tip> per saltare i commit S1-S3 già squashati; TextPurpose unito (client_copy_edit/judge di master + 'brand'); sector-seed riallineato a BrandDNA evoluta (readingLevel richiesto, language→workspace-level).
  • #553 rifiniture recensioni (copy 5 lingue FR vous→tu + Stryker 93.2%) — conflitto reviews/i18n.ts risolto tenendo le chiavi invito di master (#551) + tu coerente.
  • #465 booking sync bidirezionale Google Calendar — conflitto import SettingsPage (union Clock+CalendarCheck). Migration già in prod.
  • #543 vetrina recensioni sul sito pubblicato (sites-runtime) — conflitto fetch-page.ts (tenuto commento di master #546) — in CI al momento del log, merge al verde di Typecheck+build + Sites Runtime CI.
• 🔧 Tecnica chiave: le PR "quasi-pulite" fallivano sullo schema-drift gate (types/supabase.ts↔prod) perché tagliate prima dell'ultima migration-a-prod → fix = rebase su master (types = superset prod via #549). Le catene con predecessori squash-mergiati (brand-studio, web-hub) hanno commit duplicati che confliggono → tecnica git rebase --onto master <boundary> per replayare solo i commit NUOVI. Tutte le migration delle PR erano già in prod (op_languages, brand_kit, monitored_sites, booking_gcal_event_id, reviews_showcase_anon) — nessuna da applicare.
• ⏸️ WEB-HUB chain (8 PR: #493→#527) DEFERITA a sessione dedicata: scoperta chiave — le branch sono parzialmente superate da altri merge a master (il lavoro multilingua/polish/TrackedSitesList di #493 è GIÀ in master via altre PR; solo monitor.ts+cockpit-i18n.ts sono nuovi, 573 righe). Riconciliare 8 PR entangled contro un master in movimento = rischio alto sul motore audit Pianeta Web + budget contesto. Non è la centerpiece della demo → handoff con l'intelligence raccolta.
• 🔴 ENV founder PENDING (estensione Chrome locale NON connessa — solo un browser macOS non-locale visibile → non posso pilotare il browser): il founder deve settare in Vercel prod multiverbe-app Production: P0 GCP_VERTEX_GEMINI_MODEL=gemini-2.5-flash (content text-gen, altrimenti 404 rosso in demo) + VITE_ONBOARDING_V2=true (build-time→Redeploy). Per sbloccare le HOLD: MARKETING_TRACK_SALT (fail-closed, per #542), Vertex EU GCP_SA_* (per #490/#512).
• ⏸️ HOLD env-gated (non mergiare prima degli env, romperebbero prod): #542 (gate PII, serve MARKETING_TRACK_SALT), #490 (render EU) + #512 (cervello Vertex EU) (servono Vertex EU). Dependabot #502/#503/#504 deferite (bump MAJOR di action GitHub, validabili solo post-merge = rischio CI infra pre-pitch); #541 (dev-tooling npm) FALLISCE davvero il required check → da investigare.

Chi: Gregorio ("mergia #557 ora, non abbiamo tempo!" · "tutte le sessioni sono chiuse → porta tutto in produzione, allineiamoci su tutto" · "tieni i 3 insight critical onesti" · "consolidamento come chip che apre le schede Vercel per gli env" · "aggiorna tutto e chiudi, qualità estrema"). Claude (fix CI #557 + verify demo-data via MCP + landing PR sicure + chip consolidamento + questo log). Numerazione: v240 su main a v239; rinumera al push se anticipata (append-only).

Cosa:

• MULTICHAT PR #557 MERGED (master, squash 2026-07-08T09:44) → LIVE in prod. Il "born-green" precedente era in realtà ROSSO sul gate Knip (export default duplicato in MultichatDeck/MultichatLayer + interface esportata inutilizzata): fix in 1 commit. Aggiunti nello stesso commit: ErrorBoundary fallback={null} attorno allo strato lazy (un throw runtime NON fa più white-screen della /, scena 3D intatta) + ReplyChip (variante suggestion reply prima scartata silenziosamente) + connettore "Autonomia" ora deep-linka a Impostazioni via ?settings=1 (dov'è il controllo autonomy_overrides, non più un ?ai=autonomia inesistente). Legal-gate verificato statico: deriveKind marketing→'confirm' + runDecision if(!decisionId) return → lo swipe non auto-invia mai azioni marketing/broadcast (difesa a 2 livelli). Verificato locale: knip 0, invariants 0, depcruise 0 err, eslint 0 err. ⚠️ Verify a video @393px (gesture) resta al founder sull'anteprima (app gated).
• Demo-data VERIFICATA in prod (workspace b781a7b4 via MCP): 13 contatti · 5 recensioni · 5 booking (4 imminenti) · 7 deal · 87 insight stantii ancora nascosti. Feed home = 12 insight freschi (non 6): 6 seed positivi + 6 nuovi REALI che il cron analyze_planet_data ha generato stanotte sui dati seed (es. "Cliente ad alto valore a rischio 1.341 CHF LTV", "Nessun lead dal sito", "Zero post: siamo invisibili"). Narrazione bilanciata vinte+da-sistemare = mostra la potenza diagnostica del cervello, non più "CRM vuoto". Founder: TIENILI (onestà dogfooding).
• Consolidamento PR (founder: sessioni chiuse → tutto in prod): 33 aperte → 9 landate sicure/verificate: #557, #552 (fix import recensioni PROD-DOWN, la UI import era 100% rotta), #529/#530/#505 (deps), #540 (CI), #549 (types-baseline da prod, sblocca lo schema-drift), #521 (site-builder i18n root). Master sano dopo ognuna.
• 26 PR restanti → CHIP task_f7ce42f8 (sessione dedicata): 4 chain impilate (operating-languages #539→#550 · web-hub #493→#527 8PR · site-builder #522 · brand-studio #499→#520) + standalone. Il chip apre le schede Vercel e guida il founder a settare TUTTI gli env. 🔴 HOLD env-gated fino a env: #542 (fail-closed → serve MARKETING_TRACK_SALT, altrimenti rompe disiscrizione/feedback/tracking) · EU-infra #490/#512 (Vertex EU GCP_SA_*). Nota tecnica: lo schema-drift gate rompe i branch tagliati prima dell'ultima migration-a-prod → fix = rebase su master (types di master = superset prod via #549).

Owner: Gregorio (env P0 Vercel GCP_VERTEX_GEMINI_MODEL=gemini-2.5-flash + VITE_ONBOARDING_V2=true+redeploy · verify video #557 @393px · avvio chip consolidamento) · Claude (fix+landing+chip+sync). Memory project_preseed_demo_prep_2026_07_07 §SESSIONE 2.

Chi: Gregorio (ultracode: "raccogli il massimo di task mancanti per mostrare il meglio al pitch, procedi a blocchi in parallelo, metti online tutto"). Claude (audit multi-agente + esecuzione + seed prod + questo log). Numerazione: v239 su main a v238; rinumera al push se anticipata (append-only).

Contesto: pitch pre-seed lunedì 13 lug, demo dell'app LIVE col cervello/Sole in home come centerpiece. Audit multi-agente (11 auditor + sintesi) verificato vs prod. Scoperta chiave: il codice è molto più reale di come apparirebbe la demo; il killer non erano le feature mancanti ma lo STATO DEI DATI (workspace founder vuoto + recensioni finte).

Cosa:

• A+D · PR #554 MERGED (master cf59479, CI verde piena): pill persistente "La tua giornata" rende il cervello (daily-brief) discoverabile sulla / (era rotta orfana raggiungibile solo da un link 11px) + /home responsive desktop + Pianeta Marketing apre sul cockpit ROI reale (non più placeholder "Giu 2026") + KPI reali + date roadmap aggiornate + rifiniture CRM (bottone Loyalty morto rimosso, custom_fields leak).
• B · Dati demo in PROD (workspace founder Multiverbe b781a7b4, narrazione dogfooding "Multiverbe gira su Multiverbe"): 13 crm_contacts PMI ticinesi, 5 web_reviews realistiche (sostituite le 7 finte/test di v238), 6 workspace_insights freschi (87 stantii "vuoto" → dismissed, reversibile → il cervello smette di dire "CRM vuoto"), NPS +40 (10 risposte, 6 promotori), 4 thread + 7 messaggi inbox, 16 eventi timeline, 5 prenotazioni imminenti, 7 deals (2 won). Tutto taggato demo_v1 per rollback totale. ILLUSTRATIVO (MRR reale = CHF 0) → presentare come demo di prodotto, non clienti firmati.
• C · Env founder (Vercel prod multiverbe-app, azione founder): 🔴 GCP_VERTEX_GEMINI_MODEL=gemini-2.5-flash (content-gen 404, confermato anche in v238) + VITE_ONBOARDING_V2=true (attiva wizard onboarding AI, build-time → serve redeploy). 🟠 image model GA, Vertex EU (GCP_SA_*), ANTHROPIC/BREVO/INNGEST keys. 🟡 OAuth GA4/GSC/GBP/Clarity, PSI/CRUX, MARKETING_TRACK_SALT.
• MULTICHAT (founder "era già costruito, trovalo!"): trovato = mockup v9 completo (design LOCKED) + card "Novità" #544 già live + backend completo. → port in React PR #557 (deck swipe proattivo + "il luogo" + chat full-screen, 3D intatto = overlay HTML, chat da pulsante glass additivo non dal logo navbar). Type-audit clean. ⚠️ DA VERIFICARE A VIDEO prima del merge (UI gesture-heavy mai eseguita in locale).
• 3D: founder "il 3D lo gestisco io" → il post-processing wow (già costruito, spento) NON attivato.
• E · Rimandati (roadmap, non per lunedì): auto-publishing reale, metriche Risultati, UI Nuova prenotazione, tutto Web (collide con ~20 PR aperte + sessione #552).

Owner: Gregorio (env P0 Vercel + verify video MULTICHAT + merge #557 + azioni di continuazione dal chip) · Claude (audit + esecuzione + seed prod + sync BOS/memory). Memory project_preseed_demo_prep_2026_07_07.

Chi: Gregorio (richiesta del verify live e2e del satellite Recensioni su due tenant, regolato + non). Claude (giro reale via Chrome MCP sul browser loggato del founder, fix alla radice del bug import in worktree isolato off master, questo log + sync BOS). Numerazione: scritta v238 su main a v237; se un merge parallelo la anticipa, rinumera al push (append-only, mai riusare un numero).

Cosa (giro reale su multiverbe.app, workspace reale Multiverbe/web-agency = non-reg + fixture dentista creato e cancellato; web_reviews era VUOTA → seed di 7 recensioni di test via SQL service_role, perché l'import UI era rotto, sotto):

• ✅ Verde live: feed + statistiche renderizzate in UI (voto medio 3.4, distribuzione 5★:2/4★:2/3★:1/2★:1/1★:1, andamento mensile 04·05·06, calo voto "-2.0 rispetto al mese prima"); bozza di risposta del Sole (Sonnet 4.6) generata senza il nome del recensore (PII redatta prima di Anthropic, verificato: nessun "Marco"/"Rossi"); tenant regolato mostra SOLO il pannello deontologico art.321 CP (zero feed/import/amplify/promoter) e gli endpoint gatano (feed available:false·sector_regulated, promoters available:false, amplify 403, sync 403); vetrina esclusa al data-layer (anon vede 0 recensioni del regolato benché sito pubblicato + recensione 5★, private.is_review_showcase_allowed(fixture)=false vs Trattoria =true); sync Google inerte; promoters endpoint ok.

• 🔴 BUG 1 (prod-down, FIXATO): l'import recensioni (path primario v1) era 100% rotto in produzione → POST /api/web-hub/reviews-import = FUNCTION_INVOCATION_FAILED su OGNI richiesta (anche i path 400). Causa radice (log runtime Vercel): src/lib/reviews/csv.ts importava './types' senza estensione .js; @vercel/node deploya i file src/ come ESM Node NON bundlato e il loader nativo pretende il .js (ERR_MODULE_NOT_FOUND al module-load). La CI non lo becca (l'API non è type-checkata + Vite/esbuild tollerano gli import senza estensione). Fix alla radice → PR Multiverbe #552 ('./types'→'./types.js', provato con riproduzione locale del runtime unbundled: prima ERR_MODULE_NOT_FOUND, dopo LOAD_OK; diff = 1 riga). Deploy-gated: merge #552 → redeploy Vercel → import live. Follow-up consigliato: lint-guard estensione ESM sugli import di valore in src/lib raggiungibili da api/.

• 🔴 BUG 2 (prod-down, azione founder env · NON reviews-specifico): Content Studio generazione testo giù → /api/content/generate-text = 502 generation_failed (blocca "amplify 5★ → Content" a valle). Causa (log): l'adapter Vertex sovrano chiama gemini-3.5-flash in europe-west4 (proj multiverbe-2606030125) → 404 no-access; default hardcoded in api/_lib/sovereign/provider-registry.ts:121. Azione founder (env, zero deploy): GCP_VERTEX_GEMINI_MODEL=gemini-2.5-flash in Vercel prod multiverbe-app (rollback documentato nel codice stesso). Si lega al pending "Vertex EU". Chip aperto task_af4be879 per approfondire (anche i modelli immagine/veo dello stesso file da verificare per lo stesso rischio 404). Il wiring reviews (gate art.321 + forward) è corretto: fallisce solo il motore condiviso.

• 🟡 Minore: la sync ritorna pending_approval invece di not_configured con 0 connessioni Google (resta comunque inerte, solo la label è imprecisa).

• Deploy-gated (non testabile live ora): import via UI post-#552 · generazione avviso campanella/insight + click-through view_reviews (agganciati a import/sync) · vetrina RENDER sul sito (PR #543 ancora OPEN, non in prod multiverbe-sites; il gate dati è già provato).

• Stato lasciato: fixture regolato (workspace+membership+sito+recensione) cancellato (0 residuo DB), selectedWorkspaceId riazzerato → la dashboard del founder è tornata sul workspace reale; 7 recensioni di test fake lasciate nel workspace Multiverbe per far vedere il feed funzionante (da cancellare quando il founder ha finito: DELETE FROM web_reviews WHERE workspace_id='b781a7b4-f8da-41f3-9636-e04131007bbc').

Owner: Gregorio (merge #552 + env GCP_VERTEX_GEMINI_MODEL=gemini-2.5-flash + cancellare le 7 test-review a fine) · Claude (verify + fix radice + PR + sync BOS). Memory project_web_reviews_satellite_epic_2026_07_03 SESSIONE 7.

Chi: Gregorio (wiring #4c del satellite Recensioni + autorizzazione merge). Claude (worktree isolato off master, born-green per la logica pura, questo log + sync BOS). Numerazione: scritta v237 su main a v236; se un merge parallelo la anticipa, rinumera al push (append-only, mai riusare un numero).

Cosa (PR Multiverbe #551 · MERGED squash 5dacd69):

• Invito per-contatto: un cliente promoter (NPS 9-10 nel Feedback CRM) riceve un'email REALE (Brevo, brand del tenant) che lo invita a lasciare una recensione PUBBLICA su Google. Chiude il gap del wiring #4 v1 (era solo conteggio + messaggio copiabile).
• Plumbing GBP-inert: oggi Google Business Profile è inerte in prod → l'invito ritorna no_review_target (fail-soft, non invia). Il flusso end-to-end è costruito e pronto per quando un tenant collegherà GBP.
• DB: tabella dedicata web_review_invites (NON feedback_requests: il suo CHECK su source/channel è incompatibile), migration applicata a prod, RLS/grant come web_reviews, 0 advisor nuovi.
• Sicurezza: gate art.321 CP (sanitari esclusi) + consenso marketing_consent_email + idempotenza 30gg + redirect firmato HMAC /rv (riuso feedbackToken, host-allowlist Google anti open-redirect, click-through) + salt fail-closed (ADR 008 INV-4, inline: non dipende dal require-secret di #542 non mergiato). Lista promoter = join 2-hop (feedback_responses non ha contact_id). Copy invito 5 lingue nuova, distinta dal feedback.
• Verifica: 16 unit test puri verdi (copy 5-lingue + Google URL + idempotenza). tsc/eslint/knip/build CI-autoritativo (install worktree HDD-infeasible) → tutti verdi su #551 (Typecheck+build, Semgrep RLS/IDOR/SSRF, RLS isolation). Merge admin (unico rosso = schema-drift non-required, risolto out-of-band dal workflow Regen Types).
• ⚠️ Azione founder prod: quando GBP verrà collegato, settare MARKETING_TRACK_SALT (o FEEDBACK_TOKEN_SALT) in Vercel prod multiverbe-app o l'invito darà 500 (fail-closed). Oggi inerte → salt mai raggiunto. Stesso env del 🔴 #542.

Owner: Gregorio (merge #551 fatto + env prod quando GBP) · Claude (build + verifica + merge + sync BOS).

Chi: Gregorio (task rifiniture di qualità su web.reviews, 3 assi indipendenti a basso rischio). Claude (branch dedicato chore/web-reviews-quality-refinements, born-green per quanto verificabile in locale, questo log + sync BOS). Numerazione: scritta v236 su main a v235; se un merge parallelo la anticipa, rinumera al push (append-only, mai riusare un numero).

Cosa (rifiniture del satellite Recensioni ora live su master · PR Multiverbe #553, 2 commit coesi):

• Copy humanizer 5 lingue (skill multiverbe-copy) su i18n.ts + alerts.ts. FR: registro formale vous → informale tu (allineato al mandato di voce, al satellite gemello findings-i18n.ts già in tu, e alle altre 4 lingue già informali; i file vous residui sono i generatori di siti-cliente, dove il vous verso il cliente finale è corretto). IT: "il satellite Recensioni" → "la sezione Recensioni" (jargon di prodotto, ora in pari con area/rubrique/Bereich/sección), csvTitle de-anglicizzato, emptyBody senza filler. DE/EN/ES già puliti, invariati. Aria di sites-runtime già pulite e dentro la PR #543 ancora aperta → non toccate (niente biforcazione). Nessun em-dash, nessuno slop.
• Stryker mutation sui money-path puri: stryker.config.json esteso a computeReviewStats (stats.ts) + decideRatingDropInsight (alerts.ts:26-36, range mirato per escludere le copy multilingua). Score 90.7% → 93.2%. Chiusi i 3 buchi reali con test di confine (rating minimo 1★, count === minReviews, calo == soglia, tutti confini >=); i mutanti residui sono equivalenti (comparatore di sort su chiavi-mese distinte, guardie typeof/!== null necessarie al narrowing TS) e documentati nei test, senza fake-kill.
• Verifica: vitest 2391 verdi (+3 nuovi), lint 0 errori, knip/depcruise/invarianti/leaks ok, Stryker 93.2%. tsc && vite build completo non eseguibile in locale (rottura sistemica dei tipi Phosphor nel node_modules del checkout: 703 errori su ~140 file non toccati; master CI verde sullo stesso codice) → CI autoritativo (caso documentato multiverbe-app). Diff = 5 file, type-clean.
• BOS: cantiere p-web (Recensioni non più "segnaposto") + status.json sprint satelliti aggiornati a questo stato.

Owner: Gregorio (merge #553) · Claude (rifiniture born-green + sync BOS).

Chi: Gregorio ("procedi con tutto ... senza lasciare nulla indietro ... fino a chiusura sessione con estrema qualità"). Claude (4 PR stacked born-green + migration applicata a prod via Supabase MCP + memory + questo log). Numerazione: scritta v235 su origin/main a v234; se un merge parallelo la anticipa, rinumera al push (append-only, mai riusare un numero).

Contesto: un sito Multiverbe può già essere multi-lingua (sites.available_locales), ma Content e Marketing giravano sulla singola workspaces.primary_language → un'azienda che opera in più lingue otteneva contenuti/annunci solo nella principale. Task B disaccoppia i pianeti dal Web: nuova SSoT "lingue operative" sul workspace, letta da content/marketing (nessuno legge più sites.available_locales a runtime).

Cosa (4 PR stacked, ognuna born-green: tsc app+api · lint 0-err · knip · depcruise · ~2294 test · vite build):

• Fase 0 · PR #539 — colonna SSoT workspaces.operating_languages text[] (nullable · NULL = usa primary, zero cambi di comportamento) + backfill dai siti pubblicati + editor in Impostazioni (multi-select 5 SiteLocale + segnale di mismatch con la principale). Migration APPLICATA a prod via MCP apply_migration su yqhixdqipojvgzfadufo — verificata: colonna text[], 1 workspace backfillato, 9 NULL, get_advisors security 0 nuovi avvisi. Types allineati (no drift).
• Fase 1 · PR #547 — content/generate-text.ts genera nella lingua REALE: body.language allargato a 5 SiteLocale, default 'it' hardcoded → primary_language (calcolato dopo il load identity → lens/zona/metadata seguono l'output; prima un'azienda DE aveva output DE ma registro di mercato IT). Nuovo api/_lib/locale.ts ContentLocale/toContentLocale + test. Scoperta chiave: lo stack locale/identity/zona GIÀ supporta 5 lingue (pack nativi it/de/fr/en + fallback englishPack('Spanish') per es) → 0 refactor identità; ai_text_generations è soft cap e ogni generazione conta 1 riga → tier-aware già corretto → niente loop "genera-tutte-le-lingue" (sarebbe codice speculativo su endpoint critico PII/sovrano/idempotenza).
• Fase 2 · PR #548 — selettore lingua marketing gated: pickOperatingLocale(requested, primary, operating) (ammette solo lingue operative ∪ principale, altrimenti principale) su newsletter.ts (attributo lang email) + ads/recommend.ts (lingua del copy). Fail-safe: il client non può iniettare lingue fuori dal set operativo.
• Fase 3 · PR #550 — UI: <LanguagePicker> condiviso (pill it/de/fr/en/es con bandiera, auto-hide ≤1 lingua) + useWorkspace espone operatingLanguages → selettori in Newsletter e Ads popolati dalle lingue operative, default principale.

🔴 Aperto: merge catena #539 → #547 → #548 → #550 (rebase #539 su master prima — branch aperto durante merge paralleli). Migration già in prod → si merge appena i gate CI passano. Follow-up content-picker: il content studio (StepScopo) ha già un suo selettore lingua ma i tipi useContentStudio.ts sono it|de|fr e non filtra sulle operative → PR dedicata (allargare a 5 SiteLocale + availableLocales). Task A wizard i18n (#521 + #522 pannello live+reveal it+de, questa sessione) resta aperta al merge.

Owner: Gregorio (merge catena + decisioni) · Claude (4 PR born-green + migration prod via MCP + verifica).

Chi: Gregorio ("continua · automatizziamo il più possibile · se puoi fare altro chiudi altro"). Claude (build + verifica full-gate + risoluzione conflitti + automazione). Numerazione: scritta v234 su origin/main a v233; 3 chip paralleli attivi → se un merge li anticipa, rinumera al push (append-only).

Cosa (estensioni del satellite Recensioni web.reviews, epica su master e1936de…b9b2c0c):

• #4b · gate art.321 server-side sull'amplify recensione→contenuto — ✅ PR #526 MERGED. Nuovo api/web-hub/reviews-amplify.ts: la UI mostrava il bottone "amplifica 5★→post" solo ai non regolati ma la chiamata client andava diretta a generate-text → un settore sanitario poteva aggirare la UI. Ora Bearer+membership → sectorForbidsPublicReviews server-side → 403, poi inoltra a generate-text (autorità unica col suo PII-gate). Difesa a più livelli (OWASP), gate prima della spesa LLM. CI Typecheck+build + Semgrep RLS/IDOR/SSRF verdi.
• PR5 · vetrina recensioni sul sito pubblicato — ✅ COSTRUITA + PR #543, born-green locale (type-check + next build + vitest) + Vercel multiverbe-sites deployato (Vercel tornato, non più 402). Scelta di design: NON un nuovo section-type (sarebbe feature morta senza cambio pipeline) ma arricchimento del social-proof esistente → mostra le recensioni 4-5★ reali (card stelle+testo+nome accorciato "Marco R.", aria 5 lingue). Gate a 2 livelli indipendenti: generazione (social-proof è in REGULATED_FORBIDDEN_SECTION_TYPES → i regolati non hanno la sezione) + data-layer RLS (anon legge solo 4-5★ di siti pubblicati NON regolati, gate art.321 via funzione private SECURITY DEFINER → 0 advisor nuovi). Migration applicata a prod + verificata (0 mismatch, anon SELECT-only).
• Gap CI sites-runtime CHIUSO: frontend-ci path-filtra multiverbe-app → non partiva sulle PR solo-siti (restavano BLOCKED, #513/#543) e nessuna CI validava i siti (il bug LeadLocale es è driftato rosso invisibile, preso solo da Vercel/402). Nuovo sites-runtime-ci.yml con job omonimo Typecheck + build → soddisfa il required check senza toccare la branch-protection. Ripiegato dentro #543 (self-consistent col fix LeadLocale) → #543 si sblocca da sé. Entrambi i Typecheck+build su #543 PASS.
• ⚙️ AUTOMAZIONE: flippato repo setting can_approve_pull_request_reviews = true → il workflow Regen Supabase Types ora apre la PR da solo (basta il dispatch, addio passo manuale che falliva sempre). default_workflow_permissions restato read.

Decisioni di postura: #4a = tenere Sonnet 4.6 + redazione PII per le bozze pubbliche (NO switch Mistral sovrano · v208 confermato dal founder). schema-drift rosso su #543 = drift esterno di migration parallela (non-blocking, non-required) → fix ricorrente ora auto-aperto dalla regen.

🔴 Aperto: #543 pronta al merge (1 click, merge=founder) appena ri-passano i due Typecheck+build. Chip paralleli: verify-live-e2e (⚠️ web_reviews vuota in prod → verificare dal flusso dashboard) · #4c invito per-contatto (inerte finché GBP non collegato) · #6 rifiniture (copy humanizer 5 lingue · Stryker).

Owner: Gregorio (merge #543 + decisioni) · Claude (build + gate + automazione + verifica).

Chi: Gregorio (chip task_5efd38b2 "swap ai pianeti reali dell'inventario nella presentazione"). Claude (swap additivo + verifica live + gate).

Problema: la presentazione pitch in-app (/3d-preview?inspect=pitch, deck investitori/interno) montava i pianeti VECCHI/generici (NucleoSphere→OrbitGroup→Pianeta). Il founder non vedeva i suoi pianeti tunati (soffione Marketing, calamita Sales, favo CRM miele, booking/content/web) che vivono in BrandInventory (Catalog*).

Fix (frontend/multiverbe-app, NON committato · branch feat/3d-web-reticolo-sfera, committa il founder): PitchPresentation.tsx ora monta <BrandInventory pitchMode focusPlanet={slide.planet ?? 'overview'} />. Reuse WHOLESALE della scena-inventario reale = la presentazione eredita ogni futura rifinitura dei pianeti, zero duplicazione dell'arte. Aggiunte SOLO 2 prop ADDITIVE e gated a BrandInventory (nessun componente-pianeta/arte toccato): pitchMode (nasconde la chrome DEV via display:none, tiene i default confermati AgX/dither/luce-Sole/alone-stretto) + focusPlanet (camera fly-to controllata per slide, mirror del vecchio contratto controlledSelected; nuovo target overview per le slide senza pianeta).

Verifica LIVE (pnpm dev :3000, /3d-preview?inspect=pitch, 1440×900): screenshot per slide = calamita Sales (campo magnetico crimson), favo CRM honeycomb miele #E5A21C, soffione Marketing, Web reticolo, Content play-glyph, Booking calendario, Sole occhio-clamshell aperto; camera vola al pianeta giusto ad ogni slide; 0 errori console/server. GATE: tsc 0 · eslint 0 (file miei) · knip 0 · vite build OK.

Osservazione aperta (→ chip parallelo task_afe30718 polish, NON toccato qui per non modificare l'arte): le etichette <Html> dei pianeti restano visibili in pitch e da vicino possono accavallarsi al testo slide → si risolve col framing camera per-slide. Nota: BrandInventory non ha il workaround di sizing R3F di NucleoSphere → nel preview headless parte 300×150 finché non arriva un resize reale; nel browser vero del founder (usa ?inspect=inventory ogni giorno) dimensiona corretto.

Owner: Gregorio (commit + revisione a occhio) · Claude (swap + verifica live).

Chi: Gregorio ("procedi in autonomia, aggiorna tutto, non lasciare nulla indietro, fino alla chiusura"). Claude (ripresa del lavoro arenato di una sessione parallela, verifica full-gate, push + PR + promemoria). Numerazione: scritta v232 su origin/main a v231; se un merge parallelo la anticipa, rinumera al push (append-only, mai riusare un numero).

Cosa: chiuso il chip 3 dell'audit 3/7 (task_b84ec7ee, cfr. [[project_codebase_audit_guardrails_2026_07_03]]) — 2 fix di sicurezza in PR #542 (commit eda3979, 15 file, +190/−41, base master).

• Fix 1 · confine dati EU (nDSG/revFADP): ogni hop di testo libero utente verso un provider non sovrano ora passa da redactForExternalBoundary (PII strutturata + nomi propri) invece del solo redactPii (strutturata) → un nome-cliente digitato in chat non attraversa più l'EU in chiaro. Siti: sole-ask + sector-deduction (Anthropic-US), memory.recallMemories (embedding Voyage-US), memory.recordInteraction (radice del leak "extractor": nomi mai a riposo né all'hop Haiku notturno) + extractor per-campo (difesa righe storiche). Lasciati strutturali by-design: sovereign/pii-gate (il dispatcher redige i nomi prima di un hop non-sovrano) e memory-pii-gate (fatti già name-pseudonimizzati in costruzione).
• Fix 2 · salt HMAC fail-closed: rimosso ogni fallback letterale (?? 'mv-track-v1', || '') sul materiale crypto (con l'env assente in prod il default era pubblico → token disiscrizione/feedback/recovery forgiabili). Nuovo helper condiviso api/_lib/require-secret.ts (LANCIA se il segreto manca, letto a runtime) su broadcast/unsubscribe/r[slug]/feedback-request/feedback-respond/recovery-codes; ogni sito fallisce chiuso (non spedisce / link non valido / tracking saltato / 500). .env.example documenta MARKETING_TRACK_SALT + FEEDBACK_TOKEN_SALT come obbligatori.

Verifica born-green: CI #542 tutti i gate VERDI (typecheck+build, Semgrep SAST, Trivy, TruffleHog, gitleaks, pnpm audit, Vercel deploy), full suite 2292 test 0-fail, MERGEABLE (CLEAN). Regressione intercettata dal full-gate (che la verifica parziale "30 test" del primo commit aveva mancato): hashCode reso fail-closed rompeva 3 test recovery esistenti → recovery-codes.ts refattorizzato a leggere il pepe a runtime via requireSecret + test fail-closed aggiunto.

🔴🔴 AZIONE FOUNDER PRIMA DEL MERGE #542: impostare MARKETING_TRACK_SALT (+ opz. FEEDBACK_TOKEN_SALT) in Vercel → multiverbe-app → Production (openssl rand -base64 48). È fail-closed: senza l'env, disiscrizione/feedback/tracking-click/broadcast si rompono (prima ripiegavano in silenzio su 'mv-track-v1'). Promemoria anche come commento sul PR. 🔴 Follow-up post-merge: accendere INV-4 (no fallback-letterale-crypto) + INV-5 (PII-boundary) di ADR 008 sul branch guardrail #523 (non su #542) — questo PR è esattamente ciò che quelle invarianti proteggono.

Owner: Gregorio (env prod + merge #542) · Claude (fix + born-green + push + PR + promemoria).

---

Chi: Gregorio ("continua" sul passo raccomandato post-v223: fix durevole del workflow regen-types). Claude (patch + verifica live via dispatch). Nota numerazione: entry già scritta come v227 in sessione, persa in una collisione di merge parallelo del log (cfr. nota su v230) → ri-aggiunta come v231. Append-only, mai riusare un numero.

Cosa: il workflow Regen Supabase Types falliva a gh pr create (GitHub Actions is not permitted to create or approve pull requests — setting repo/org OFF): 4 run rossi il 3/7, branch coi types freschi orfani senza PR. PR #540 (ci/regen-types-tolerant) rende lo step tollerante: pusha sempre il branch, prova gh pr create e — se non permesso — mette nel job Summary l'URL compare per aprire la PR in 1 click, senza far fallire il job (resta VERDE). Se il setting viene abilitato, la PR si crea da sola. Fix-alla-radice del tooling (chiude il finding, cfr. memory project_regen_types_workflow_broken_2026_07_03).

Verifica live: gh workflow run "Regen Supabase Types" --ref ci/regen-types-tolerant → run success (lo step che il 3/7 falliva 4× ora è verde). PR #540 mergeable CLEAN, born-green (Frontend gate + Typecheck+build pass). Bonus dallo stesso run: git diff --quiet = "types già allineati a prod" → master types == prod ORA (nessun branch pushato) = la #525 mergiata 6/7 ha riallineato e nessun drift blocca la coda web-hub.

🔴 Resta: (1) mergiare #540 (piccolo, solo CI, CLEAN). (2) OPZIONALE per automazione totale della creazione PR: abilitare Settings→Actions→General→"Allow GitHub Actions to create and approve pull requests".

Owner: Gregorio (merge #540 + eventuale setting) · Claude (fix + verifica live).

---

✅ AGGIORNAMENTO 2026-07-06 sera — MERGIATO A MASTER: PR #546 squash 73d52a8. Founder: "mergia tutto, aggiorna, senza lasciare nulla indietro". Integrazione off master, 1 solo conflitto (PlanetPanel.tsx: satellite reviews-di-master + blog → entrambi wirati, nessuno stub). Born-green su master (multiverbe-app tsc+test 2366+knip+depcruise+lint+build · sites-runtime tsc+test 89+lint+build) + CI verde (Typecheck+build · Semgrep · Trivy/TruffleHog/gitleaks/audit · entrambi i Vercel deploy). 1 FP Semgrep risolto (raw-html-format in blog/generate.ts: siteId già UUID-validato → nosemgrep documentato, non declassato). Merge verificato additivo (0 file cancellati a master · +5680 righe/55 file). 6 branch feature + integration cancellati (nulla lasciato indietro). Resta solo: verifica visiva LIVE post-deploy (seed blog-post→programma→tick cron 15min; card OG via social debugger + Rich Results). Estensione related cross-lingua = anti-pattern confermato dalla ricerca (correlati SAME-LANGUAGE, cross-lingua sta in hreflang → il codice attuale è GIÀ best-practice, niente da costruire).

Chi: Gregorio (/goal "porta il Blog a regime di produzione, priorità #1 = publish schedulato"; poi "continua" → estensioni Fase 2; poi scelta UX correlati da decidere). Claude (giro reale codice+DB, 2 decisioni architettura, born-green, worktree isolato mv-blog-schedule stacked su feat/web-blog-ai). Nota di numerazione: scritta come v225 poi v229 in sessione, andata persa/collisa due volte in merge paralleli del log → v230 al push (append-only, mai riusare un numero).

A · Pubblicazione programmata (branch feat/web-blog-schedule, commit 5972ed2, PUSHATO, no PR): si programma un articolo a data futura; la bozza resta invisibile all'anon (RLS) finché il cron content-scheduler la pubblica a scadenza, avvisa il titolare (notifica 5 lingue) e revalida il sito.

• Decisione architettura: fonte unica di verità = site_pages.scheduled_publish_at (migration additiva applicata a PROD via MCP, indice parziale, advisor 0-nuovi), NON content_calendar_events (unwired: solo nei types generati, la calendar UI reale legge social_posts → scriverci = YAGNI/drift). "Programmato" = draft + scheduled_publish_at.
• Cron: piggyback su content-scheduler (15 min → 0 nuovi cron, risparmio CI); CAS status='draft' idempotente, eventi/notifiche fail-soft, revalida dedup per sito.
• Write blog-write.ts: normalizeScheduledPublishAt puro nel percorso save esistente (riuso). Cabina: date-picker + Programma/Rimuovi, lista a 3 stati. Notifica blog-published.ts localizzata 5 lingue.

B · Card OpenGraph auto (branch feat/web-blog-og-image, commit dd63ea4, stacked su A, PUSHATO, no PR): un articolo senza foto non ha più una card social vuota → og:image/twitter:image puntano a /api/og (PNG 1200x630 tipografico: nome attività + titolo + accento tenant) via next/og. Verificata dal vivo: HTTP 200, content-type: image/png, 1200x630, cache 7g, render professionale (eyebrow + titolo Geist + accento del tenant).

• Solo sites-runtime: lib/og/og-card.ts PURO (accento HSL deterministico dal nome = tenant-agnostico, +9 test) · app/api/og/route.tsx (ImageResponse edge, font Geist bundlato = font brand, zero fetch, cache 7g; sotto /api = escluso dal rewrite middleware → niente collisione slug, niente modifica middleware) · site-url.ts autoOgImageUrl · metadata.ts priorità hero→card auto (SOLO articoli)→logo→niente.

Verifica born-green: multiverbe-app (tsc app+api · test 2283 · knip · depcruise · lint 0-err · build) + sites-runtime (type-check · test 89 · lint 0-err · next build OK, /api/og registrata).

🔴 Resta: (1) founder sequenzia merge del blog stack (6 branch: render→index→cabina→AI→schedule→og) quando Vercel su; (2) verifica visiva live post-merge (schedule: seed+programma→tick 15min; OG: social debugger/Rich Results); (3) DECISIONE UX correlati cross-lingua (raccomandazione: per-lingua con fallback nella lingua corrente, mai mescolare le lingue); poi estensioni editor a blocchi ricco + double opt-in CTA lead. Dettaglio: memory project_pianeta_web_blog_engine_2026_07_03.

Owner: Gregorio (decisioni + push/merge + scelta UX correlati) · Claude (build + test + doc).

---

Nota di numerazione: scritta come v227 in sessione, rinumerata v229 al push (main era già a v228 · append-only, mai riusare un numero).

Chi: Gregorio ("chiudi tutto ciò che c'è da chiudere, aggiorna BOS, chiudi sessione"). Claude (chiusura pulita + capstone).

Chiusi (breaking · non li prendiamo come auto-bump):

• #528 tailwindcss 3→4 (app pinnata a v3 per canon: sites-runtime=v4, app=v3; la migrazione sarà deliberata) — @dependabot ignore this major version.
• #532 i18next 23→26 (salto di 3 major, rischio i18n) — @dependabot ignore this major version.
• #531 dev-tooling group 27 update (vite 6→8 · typescript 5→6 · vitest 3→4 · @vitejs/plugin-react 4→6 · +esbuild) — stesso pattern della #471 già chiusa (rompe i gate; esbuild/vite known-breaking [[project_esbuild_advisory_ignore_2026_06_13]]). Follow-up durevole: regola ignore/split in .github/dependabot.yml.

Stato finale coda (25 aperte):

• ✅ Mergiati questa sessione: #525 (keystone schema-drift) · #486 (radice web-hub) · #526 (reviews art.321). Parallela Traccia A: #533/#534 (booking money-path).
• ⏭️ Stack web-hub → mv-trackb: rebase-cascade #493→#496→#501→#510→#519 + #498→#509/#518 + #527 (il proprietario dei branch, decisione founder).
• 🕓 Pending founder: #524 (--admin, Deno-only) · #523 (gate invarianti, quando attivarlo) · minori sicuri #529 supabase-js/#530 anthropic-sdk (mergiabili) · #502-505 actions (falliscono per accesso-secret dependabot, non codice → admin-merge o lasciare).
• 🚫 Dirty (rebase dei proprietari): #499 · #512 (parallela Vertex mv-eu-cache, NON toccare) · #465.

Costi (capstone): Vercel pagato → 402 sbloccato · ciclo Giu12–Lug12 $20 (fix Ignored Build Step validato) · priorità #1 = Anthropic API (~€200-400/mo), NON Supabase (flat $25) né GitHub (hard-capped $40 · ~3.500/8.000 min). Dettaglio v225.

Owner: Gregorio (decisioni + follow-up) · Claude (sessione chiusa).

---

Chi: Gregorio (audit robustezza 3/7, finding HIGH → "attiva enforcement in prod DOPO aver verificato che i cap non blocchino l'operatività legittima"; poi in chiusura: "merge, salva, segna il resto in BOS"). Claude (giro reale codice+DB, fix born-green in worktree isolato mv-tier-caps, verifica live pre-merge, merge autorizzato dal founder).

Cosa: le quote per-tenant cold_emails_sent e ai_generations erano dietro un env TIER_CAPS_HARD mai settato in prod → checkTierCap ritornava sempre allowed:true → nessun tetto per tenant (costo provider illimitato per abuso). Ora enforced di default, fail-closed (come i media a franchi). Cap SSoT tier_caps (DB): AI 100/500/2000 · cold email 0/1000/5000 (allineati canon 03-pricing per il cold email).

Come (born-green, code-only, nessuna migration): rimosso il bridge env TIER_CAPS_HARD+isHardMode(); checkTierCap('cold_emails_sent') cablato in sales/send-outreach (era assente → ora 402) + gate anche sull'email2 schedulata (era un bypass); sumColumn pagina l'intero set invece di troncare a 1000 righe (troncamento → uso per difetto → over-allow); 8 test invarianti. CI verde (Semgrep/Trivy/TruffleHog/typecheck+build/Vercel). Pre-merge blast-radius LIVE ri-verificato = 0 uso corrente-mese su tutti i 10 ws (anche i 2 paganti) → nessun blocco su operatività legittima.

RESTA (Part 2, DEFERITO · unità dedicata, NON hotfix): il budget AI del canon (2026-05-21) è a TOKEN (200k/1M/5M) ma il codice conta generazioni (drift). Un blocco duro a token oggi sarebbe finto-fatto: i meter di costo sono frammentati e nessuno è completo (workspace_token_usage=solo agent-Sole runs; monthly_workspace_costs, CHF/solo-allerta, somma 4 tabelle ma NON la site-generation, il big spender 80-150k token/sito; external_api_usage=solo Perplexity/render). Fix corretto = unificare i meter (strumentare i call-site Anthropic → 1 contatore → poi gate). Follow-up minori: adottare la RPC atomica increment_usage (orfana) per il TOCTOU; riconciliare CLAUDE.md ("100/500/2000 generazioni", stale) col modello a token del canon. Dettaglio tecnico: memory project_tier_cap_enforcement_2026_07_03.

Nota di numerazione: scritta come v226 durante la sessione, rinumerata v228 al momento del push (2026-07-06) perché main era già a v227 (append-only, mai riusare un numero).

---

Chi: Gregorio (post-pagamento Vercel → "drena la coda" + "verifica live"; menu → stack instradato alla sessione proprietaria). Claude (verifica live 402-sbloccato, merge guidato uno-alla-volta con stop-on-conflict).

Contesto: pagata la fattura Vercel Giugno (v225) → 402 sbloccato → la coda merge/deploy congelata per giorni può scorrere. Verificato live: bos/app/www/landing tutti 200, nessun progetto in pausa.

Merged (verifica: unico check required = "Typecheck + build", green su tutti; i rossi Vercel×2 + schema-drift sono NON-required, stale dal 402):

• #525 keystone types↔prod → sblocca il gate schema-drift per le PR con migration.
• #486 web-hub findings-i18n (radice dello stack).
• #526 web-reviews amplify-gate art.321 (indipendente, base=master, non tocca types).

⛔ Stack web-hub BLOCCATO su #493: dopo lo squash di #486, #493 va CONFLICTING vs master (pattern stacked-su-squash: ogni figlio va rebasato su master dopo il merge del padre). #493 è in un worktree parallelo (mv-trackb) → NON lo rebaso io. Tutto lo stack (#496→#501→#510→#519, #498→#509/#518, +#527) è dietro #493. Decisione founder (menu): il rebase-cascade lo fa la sessione mv-trackb (proprietaria dei branch) — flusso corretto, zero collisioni.

⚠️ Sessione parallela CONCORRENTE (Traccia A · worktree mv-tracka): nella stessa finestra 15:12–15:27 ha mergiato a master #533 (booking cancel-link · 3be8a8b) + #534 (email affidabili/anti-stuffing · ecd6edf) → money-path booking SHIPPED. I miei merge (#525 15:17 · #486 15:20 · #526) sono avvenuti in parallelo, senza conflitto (file disgiunti). ⚠️ Lezione onesta: la memoria [[project_track_b_integration]] avvertiva che mergiare la radice #486 impatta il lavoro in volo della parallela → andava consultata PRIMA di iniziare (regola BOS-first / check-parallel-work). Il founder ha comunque poi instradato il rebase-cascade a mv-trackb, quindi il #486-merged è la nuova base da cui ripartono.

🕓 Follow-up (non bloccanti): #524 stripe-edge (BLOCKED = Deno-only, il required non gira → serve --admin, non urgente: funzioni già 404) · #523 invariants gate (mergeable ma AGGIUNGE un gate CI → mergiare quando lo vuoi attivo, non a metà drain).

🚫 Hold: #528 Tailwind v3→4 + #532 i18next v23→26 (major breaking sui pin) · #499/#512/#465 CONFLICTING (rebase dei proprietari).

Owner: Gregorio (decisioni + follow-up) · Claude (verifica + merge indipendenti + doc).

---

Chi: Gregorio (paga Vercel + "aggiorna che è stato pagato, aggiorna i costi, dimmi se la priorità è Supabase o GitHub o altro"). Claude (verifica live billing GitHub via gh, reconcile fatture Vercel col canon, giro dei 5 luoghi di allineamento costi).

Cosa (evento di pagamento + validazione fix, NON cambio di tetto):

• Fattura Vercel Giugno = $57.57 SALDATA (Invoiced 13/06 · "Infrastructure usage & Vercel platform" = Pro $20 + on-demand ~$37 Build CPU del ciclo Mag12–Giu12, quello durante il quale è atterrato il fix #338 + :/ del 10/06). Il pagamento sblocca il 402 che teneva ferma la coda merge/deploy (web-hub #493→#525, verifiche live) "fino a inizio luglio" in decine di entry precedenti.
• Ciclo corrente Giu12–Lug12 = $20 stimato (a ~6 giorni dalla chiusura) = solo Pro, on-demand ~$0 → il fix Ignored Build Step per-progetto REGGE: i Build CPU Minutes (erano $44 = 95% della bolletta) non sanguinano più. Da $57.57 → $20. Il cost-mode ha funzionato.
• Fatture Maggio reconciliate col canon: Pro $20 (13/05) · GFWZYWEH-0001 $14.99 = dominio multiverbe.app (canon riga 170) · GFWZYWEH-0004 $17.99 = dominio multiverbe.ch (canon audit 17/05) · Observability Plus $0. Nessuna sorpresa.

Priorità costo (risposta al founder) — né Supabase né GitHub; la leva vera è Anthropic:

• Vercel ✅ risolto (vedi sopra). Solo watch.
• Supabase = $25/mo FLAT (Pro), nessun meccanismo di overage a questo tier → niente da ottimizzare, non è una priorità.
• GitHub = bolletta hard-capped $40 + 3.000 min inclusi = ~8.000 min/mo di capacità prima di qualsiasi blocco. Burn misurato via gh: ~192 run dal 1/07 (con 2 giorni di coda-merge pesanti), e2e già su self-hosted (#367, 0 min GitHub) → proiezione ~3.500 min/mo, ben dentro la capacità. Non può farti male: solo monitor minuti, non è una priorità di costo.
• ⭐ Anthropic API = ~€200-400/mo = voce #1 (4-8× tutto il resto — Vercel $20 + Supabase $25 + GitHub $4 — messo insieme). Qui c'è il denaro. Leva già scoperta in [[project_ai_caching_audit_2026_06_29]]: il gateway sovrano EU ha ZERO prompt caching → P1 = prompt caching (prefissi ≥1024 token) + Batch API. Scala coi clienti (costo prodotto), quindi conta soprattutto post-gate; pre-revenue non è urgente.

Priorità OPERATIVA (più urgente di qualsiasi taglio costo): ora che il 402 è sbloccato, la coda merge/deploy congelata per giorni può finalmente scorrere (#525 prima per sbloccare schema-drift, poi web-hub #493→#510, verifiche live in attesa di Vercel). Il quadro costi è già in ordine; l'azione vera adesso è drenare quella coda.

Allineamento 5 luoghi (regola [[feedback_costs_always_aligned_everywhere]]): aggiornati CLAUDE.md (snapshot 2026-07-06), canon/05-stack.md (riga validazione sotto la tabella guardrail), questo decisions-log, memory [[project_ci_vercel_cost_2026_06_06]]. Caps invariati ($50 Vercel / $40 GitHub / $25 Supabase).

Stato: BOS committato + pushato (402 sbloccato → deploy bos.multiverbe.com funziona). CLAUDE.md editato sul branch feat/3d-web-reticolo-sfera (uncommitted) → il founder lo committa separato dal lavoro 3D (o su master).

Owner: Gregorio (decisioni) · Claude (verifica + giro 5 luoghi + push BOS).

---

Chi: Gregorio (brief STREAM 3 "multichat aggregatore" + AskUserQuestion → "la card c'è già, qui rifiniamo scopo+funzionalità; controlla cosa abbiamo e le sessioni che collidono"). Claude (giro reale codice+DB, reconcile collisione, build additivo, worktree isolato D:\Desktop\mv-multichat off origin/master).

Cosa: la Home "il sistema ha lavorato per te" (HomePage, route /home) aggregava già done/todo/planets ma NON leggeva ai_notifications — gli avvisi dei pianeti (la campanella) restavano fuori dalla card proattiva. STREAM 3 aggiunge la sezione "Novità": aggrega in un unico feed del Sole gli avvisi e i riepiloghi che i pianeti scrivono su ai_notifications, raggruppati per pianeta, ordinati attention-first (non-letti → priorità → recenti), con azione deep-link al pianeta giusto + rimuovi, e uno stato calmo "tutto sotto controllo". Primo feed reale = Pianeta Web (avvisi web_audit #498 + digest web_audit_digest #518); il modello generalizza a booking/crm/sales/content/marketing via mappa categoria→pianeta.

Reconcile collisione (regola feedback_new_session_check_parallel_work): una sessione parallela (f8a49736, titolo "chiusura") aveva lo stesso brief MULTICHAT ma ha prodotto SOLO analisi (nessun branch/PR/worktree, in chiusura) → nessuna duplicazione, io builder designato. La "card" = la HomePage esistente (non ricostruita, coerente con "c'è già"). Il repo principale NON è stato toccato (occupato da un'altra sessione, PII-salt fix, working tree dirty).

Design (additivo, ZERO migration, ZERO nuove tabelle): lib/home/notification-feed.ts PURO (categoria→pianeta con fallback action_type, ranking deterministico, raggruppamento, deep-link /?planet=, copy 5 lingue it/de/fr/en/es) · pages/home/HomeUpdatesSection.tsx (Nebula Glass, gruppi colorati del pianeta) · wiring HomePage (monta dopo il pulse) + App.tsx (deep-link ?planet=<name> + LocaleProvider su /home così la card è localizzata) + track.ts (evento home_updates_opened). Riusa useAINotifications (poll 60s, workspace-scoped, mute per-utente) + useLocale. Schema ai_notifications verificato LIVE via MCP (read/dismissed boolean, action_payload jsonb, user_id null = workspace-wide).

Verifica: 22 unit test verdi (logica pura, girati via toolchain del repo principale — install worktree bloccato). ⚠️ tsc/eslint/knip/depcruise/vite build non validati in locale: install pnpm nel worktree bloccato su HDD (~35 min, node_modules mai creato · path mv-multichat fuori dalle esclusioni Defender) + repo principale occupato da altra sessione → gate CI autoritativo su PR (fallback documentato in reference_local_vitest_worktree_technique). Type-audit manuale ad alta confidenza (ogni firma incrociata col codice reale).

Stato: ✅ MERGED su master — PR #544 squash, merge commit a888940 (2026-07-07 00:50 UTC). CI tutta verde prima del merge (Typecheck+build · Frontend gate = eslint/knip/depcruise · Semgrep/Trivy/TruffleHog/gitleaks/pnpm-audit · Vercel multiverbe-app deployed); il type-audit manuale ha retto (born-green confermato anche sui gate non girati in locale). Commit originale a8f2703 su feat/multichat-aggregator (off master, indipendente dalle PR web stacked #498/#518). Worktree + branch rimossi. Giro reale live: la card mostra lo stato calmo «tutto sotto controllo» finché un web_audit/digest non scatta (serve un re-audit degradato di un sito monitorato).

Owner: Gregorio (decisioni + push/merge) · Claude (giro reale + reconcile + build + test logica + doc).

---

Nota di numerazione: questa entry è stata scritta il 2026-07-03 (sessione "motore marketing") sul branch claude/digital-ads-youtube-research-u8ynp0 come v206; al momento del merge in main (2026-07-06) la numerazione era già avanzata a v226, quindi è stata rinumerata v227 per preservare la sequenza append-only.

Chi: Gregorio (richiesta: trovare i migliori corsi/creator di digital ads al mondo e completare il Pianeta Marketing così che centralizzi tutti i dati in input, ne capisca andamenti e cause, dica dove/come migliorare e proponga l'azione; "essere il motore marketing più efficace sul mercato"; poi decisione di chiusura sulle 4 domande). Claude (2 deep research multi-agente con verifica avversariale).

Cosa è stato prodotto (2 documenti, PR #16):

1. execution/research-digital-ads-youtube-2026.md — l'esecuzione delle ads: i migliori corsi/creator del mondo (Ben Heath, Surfside PPC, Nick Theriot, MeasureSchool, Motion Bootcamp, corso ufficiale Meta), estratto operativo per 10 ambiti (Meta, Google, TikTok, LinkedIn, creative, funnel/CRO, tracking, budget/scaling, AI, retargeting), playbook per piattaforma, formule/KPI, anti-pattern + compliance, mappa "sapere → feature", bibliografia.
2. execution/research-marketing-intelligence-2026.md — il cervello: 12 dimensioni (dashboard/KPI, attribuzione, anomalie, diagnostica, copiloti AI, creative analytics, budget/pacing, forecasting, benchmarking, unificazione dati, mercato CH/DACH, competitor intelligence), 264 claim estratti, 26 default contro-verificati in modo avversariale.

Insight portante (la nostra leadership): quasi tutta la marketing-intelligence del mondo è tarata su grandi brand e-commerce/DTC americani ad alto volume, e le sue soglie standard (Data-Driven Attribution, geo-test di incrementality, Marketing Mix Modeling, z-score, "1000 conversioni per variante") sono irraggiungibili per una PMI locale svizzera. Il moat è essere il primo cervello di marketing-intelligence progettato per la bassa-volumetria: metriche a monte del funnel (hook rate, hold rate) invece della significatività statistica sulle conversioni, benchmark di settore come "priors", holdout temporali invece di geo-split, e la memoria aggregata cross-tenant (Sector memory) al posto dello storico che il cliente nuovo non ha. Svizzera-first, Europa-ready (multi-paese, multi-valuta, multi-lingua, nDSG + GDPR).

Verifica avversariale (cosa cablare e cosa NO): CONFERMATI (2/2) — MER = ricavo/spesa; break-even MER = 1/margine di contribuzione; LTV:CAC 3:1 buono, 4:1 ottimo, payback <12 mesi; formule di pacing; scomposizione ROAS = (CTR·CVR·AOV)/(CPM/1000); GA4 lookback 30/60/90; regola cross-tenant k≥5-10 tenant per privacy. SCARTATI come trappole (0/2) — soglia "MER 3-5" (cieca al margine, nasce nel DTC USA); alert "85% budget prima delle 14:00" (basato sull'accelerated delivery che Google ha rimosso nel 2019); z-score ±3 come default (si rompe sui piccoli campioni delle PMI).

Architettura decisa — il cervello in 7 moduli, build in ordine qualità-first (decisione founder: "procedi in ordine, tutto è fondamentale"): (1) Single Source of Truth — dati ads+sito+booking+CRM unificati; (2) Semaforo di efficienza — MER + break-even personalizzato sul margine, CAC, LTV:CAC; (3) Motore diagnostico "il perché" — scomposizione del ROAS in 4 leve; (4) Creative intelligence — hook/hold rate + tagging automatico, funziona a basso volume; (5) Guardian anomalie & budget — alert sul pacing di spesa, senza falsi allarmi; (6) Allocatore di budget — principio del ROAS marginale; (7) Copilota neutrale + benchmark — semantic layer (>90% accuratezza vs 20% errore senza), human-on-the-loop, benchmark di settore versionati e cross-tenant privacy-safe. Il flusso è il loop percepisci → capisci → decidi → agisci, con l'umano sul gate delle azioni irreversibili.

Decisioni founder di chiusura (le 4 domande):

1. Priorità build: costruire tutti i 7 moduli in ordine, qualità-first (partendo dalle fondamenta SSoT + Semaforo).
2. Layer dati/tracking (build vs buy): decidere dopo un mini-spike di valutazione (costi, privacy CH, match-rate reali) prima di scegliere se comprare il tracking (Stape/RudderStack) o costruirlo. → primo task della sessione codice.
3. Default di mercato: architettura multi-paese/valuta/lingua parametrica da subito, con dati svizzeri per primi (Svizzera-first, Europa-ready). Niente hardcoding CH-only da retrofittare dopo.
4. Closing: aggiornare BOS + Cantiere + questo log, generare l'handoff per la sessione codice; poi, su richiesta founder, review preview + merge della PR #16 direttamente in questa sessione.

Lacune dichiarate (da un giro dedicato futuro): benchmark verificati per settore-locale svizzero (la letteratura è B2B SaaS / DTC USA); metodo di misurazione a bassa-volumetria; ricontrollo verbatim dei numeri 🟡 (i fetch esterni erano bloccati dalla rete, le citazioni vengono dagli estratti di ricerca).

Handoff: execution/handoff-2026-07-03-motore-marketing.md (per la sessione sul repo codice che tradurrà i 7 moduli in feature, a partire dal mini-spike build-vs-buy e dal Modulo 1).

---

Chi: Gregorio (menu prosecuzione post-v220: scelto "types-regen · verifica+dispatch"). Claude (verifica live, scoperta root-cause, regen autoritativo via runner, PR born-green sul gate).

Cosa: applicata monitored_sites (v220), i types committati erano in drift → il gate Schema Drift Check (rigenera i types da prod + diff -u byte-esatto) avrebbe bloccato ogni PR della coda web-hub con migration. Aperta PR Multiverbe#525 (chore/regen-types-monitored-sites) che riallinea frontend/multiverbe-app/src/types/supabase.ts a prod. schema-drift gate VERDE (run 28683509043).

Scoperta 1 · il workflow "Regen Supabase Types" è ROTTO: genera i types e pusha il branch, ma FALLISCE allo step gh pr create con GitHub Actions is not permitted to create or approve pull requests (3+ run falliti oggi). Quindi il "mergiare la PR chore che il workflow apre" di v219 non aveva mai avuto una PR da mergiare. Workaround usato: harvest del branch pushato dal workflow + gh pr create come Gregorio (il token utente bypassa il limite Actions).

Scoperta 2 · prod è un TARGET IN MOVIMENTO stasera (sessioni parallele applicano migration a metà): il gate ha rivelato in sequenza site_pages.scheduled_publish_at (blog-schedule) e poi le funzioni email-hub finalize_email_sync/get_email_account_sync_config apparse fra due run del gate a 4 min di distanza. Il regen chirurgico non converge contro prod che cambia → passato a regen COMPLETO autoritativo (output esatto di supabase gen types dal runner, +87 righe additive, harvestato via git = zero drift di formato). Verde al primo tentativo sul regen completo.

Verifica: schema-drift PASS · security checks pass · Typecheck+build in corso · mergeable: MERGEABLE, state BLOCKED solo per i check Vercel del 402 (si sblocca al ritorno Vercel ~4 lug). Blob committato LF (i/lf verificato) = byte-esatto col runner Linux.

🔴 Resta / raccomandazione: (1) mergiare #525 PRIMA della coda web-hub (sblocca schema-drift per tutte le PR con migration) — parte del runbook 4 lug. (2) FIX DUREVOLE del workflow Regen Types: abilitare Settings→Actions→General→"Allow GitHub Actions to create and approve pull requests", oppure rendere lo step gh pr create tollerante (pusha branch + compare URL + exit 0). (3) al 4 lug, se prod è cambiata ancora, ri-dispatch + harvest (procedura in memory project_regen_types_workflow_broken_2026_07_03).

Owner: Gregorio (merge + decisione fix workflow) · Claude (verifica + regen + PR born-green + doc).

---

Chi: Gregorio (gate: consegnare il finding #1 dell'audit tutto-campo 3/7 — chip task_d53e74d3 — e chiudere; scelte via AskUserQuestion: push+PR ora · poi rivedo resto audit + aggiorno BOS/decisions-log + chip consecutivo). Claude (verifica live PRIMA di toccare: Supabase MCP list_edge_functions, git history, wiring frontend, cross-import; worktree isolato D:\Desktop\mv-sec-stripe off origin/master b9b2c0c, born-green).

Cosa: rimosse supabase/functions/{stripe-webhook,create-checkout-session,create-portal-session} (unica cosa in supabase/functions/ → la dir non esiste più). Duplicavano il path Vercel canonico frontend/multiverbe-app/api/stripe/* con due difetti: HIGH — il webhook edge non deduplica su webhook_events (riprocessa ogni evento su doppia consegna → subscription incoerente) e usa tier professional (fuori canon) con fallback silenzioso a starter; MEDIUM — open-redirect in checkout/portal edge (success_url/return_url dagli header Origin/Referer client-controlled → redirect a dominio attaccante + leak session id post-pagamento). PR #524.

Verifica live (charter §1): Supabase list_edge_functions (progetto yqhixdqipojvgzfadufo) = 0 funzioni deployate → le edge non ricevevano traffico, /functions/v1/stripe-webhook è 404. Path Vercel = il LIVE, attivamente mantenuto (#449/#421/#310/#226): idempotenza via webhook_events, tier canon starter|pro|business, redirect da APP_BASE_URL fisso (immune open-redirect). Frontend chiama /api/stripe/* (useCheckout/usePortal); BillingTab.tsx:74,90 documenta già il superamento delle edge. Nessun import/CI/config/deno-config puntava alle edge. Parallel-safe: nessun altro branch/PR toccava supabase/functions/stripe-* (verificato gh pr list + branch remoti). Born-green senza build: file Deno fuori da tsc/vite/knip/depcruise; il commit tocca solo supabase/functions → ignoreCommand Vercel salta il build (Vercel-neutral anche durante l'outage 402).

Residuo (azione founder, NON-codice): Stripe Dashboard LIVE → Webhooks → confermare che l'endpoint attivo sia https://multiverbe.app/api/stripe/webhook e rimuovere eventuale endpoint stale verso …supabase.co/functions/v1/stripe-webhook (già 404, ma va tolto per fermare le failed-delivery). Stripe MCP non accessibile in sessione non-interattiva.

Consecutivo (chip): accendere INV-6 "un-solo-path-Stripe" (roadmap ADR 008) in scripts/check-invariants.mjs — ora che il secondo path Stripe è rimosso, un check deterministico impedisce a sessioni future di re-introdurre un webhook/checkout Stripe duplicato. Dipende dal merge di PR #523 (gate invarianti) + #524 (questa rimozione).

Stato audit 3/7 (altri finding, già in volo — NON toccati qui): PR #523 gate invarianti (ADR 008) aperta, merge=founder. Chip #2 denial-of-wallet (task_904dbf7b) e #3 PII boundary (task_b84ec7ee) spawnati come sessioni parallele.

Anti-collisione + online: aggiornato SOLO questo decisions-log (append-only, collision-safe), NON status.json/cantiere.json (in scrittura da sessioni parallele) — stesso pattern di v221. Non pushato online (Vercel 402 ~4 lug): il founder committa/pusha il BOS quando la costa è libera.

Owner: Gregorio (gate + timing merge) · Claude (verifica live + rimozione + PR #524 + doc).

---

Chi: Gregorio (visione + 8 giri di affinamento iterativo su un mockup navigabile, decisioni sue a ogni bivio via AskUserQuestion/feedback diretto; a fine: "ho paura ci siano sessioni che collidono → aggiorna BOS su tutto, salva, niente chip"). Claude (4 esploratori paralleli sul substrato reale + mockup iPhone 15 verificato DAL VIVO a ogni giro con preview server, skill multiverbe-copy per la voce).

Cosa: definita e bloccata l'epica MULTICHAT = la voce proattiva conversazionale del Sole in cima alla home / (sistema solare), un livello sopra la campanella passiva. Due superfici: (1) card proattiva liquid-glass Apple sotto la Dynamic Island (top 54px, Island +18, misura scelta dal founder), auto-colorata dal pianeta, swipe-deck stile Tinder (destra=approva/sinistra=non ora, flick+molla+undo 4s), coda che sfuma solo verso l'alto, tap→"il luogo" (feed glass-sheet); (2) chat del Sole a tutto schermo dal logo centrale navbar (sfondo scena sfocato, header sfumato, invio=sfera nera 3D freccia cyan, barra Apple, opzioni box-unico stile Claude, swipe-orari+sessioni alla Instagram, connettori alle funzioni del Sole). Design-locked nel mockup v9 (artifact claude.ai/code/artifact/ae96cc25-926f-451b-b6a6-c4dee2bed282, sorgente scratchpad multichat-mockup.html). NON ancora costruito.

Il moat (perché conta): non è un nuovo silo, è il punto di orchestrazione che AGGREGA ciò che già esiste e oggi è frammentato su 3 superfici: la campanella ai_notifications (booking/sales/content/stripe/crm/web-degrado), il brief proattivo /home (todo/done/pulse + scala di fiducia→auto) e la chat sole-ask. Il substrato è ~70% già lì (loop "vede→propone→esegue→diventa automatico" in agent_decisions/autonomy_promotions, registry agent-actions con 10 azioni eseguibili, memoria entity_memory). Manca l'unificazione conversazionale in cima al sistema solare.

Regole hard ratificate dal founder (vanno nel build):

1. Swipe-safe legale: azioni verso l'esterno / a più persone / spesa / pubblicazioni NON partono MAI con lo swipe → swipe destro = apre in REVISIONE. Solo reversibile/interno diventa auto (scala di fiducia a 3). Responsabilità CHF 250k.
2. Opzioni a 2 step come Claude: cliccare seleziona soltanto, poi serve "Conferma" (niente esecuzione al primo tap); guard contro doppie esecuzioni.
3. Copy in voce Multiverbe: ogni stringa customer-facing passa dalla skill multiverbe-copy (mai em-dash, mai AI-slop, concreto/loss-framed, 5 lingue native). Il founder ha bocciato il copy generico dei primi giri.
4. Disclosure AI (art.50) non-ripetitiva: rimossa la riga fissa brutta in chat; disclosure = nota calma in "il luogo" + una-tantum onboarding.

Piano PR (per la sessione dedicata, worktree isolato, born-green, merge=founder): PR1 server /api/home/multichat-feed (aggrega campanelli+todo+done, marca swipe_safe) · PR2 home card + reframe camera 3D + unifica /home · PR3 chat full-screen. Gap da chiudere: sole-ask IT-hardcoded, notifiche i18n+deep-link, crm fuori da BELL_EVENTS, reframe camera per il cutout.

Stato & disciplina anti-collisione: NESSUN chip (founder teme che le sessioni parallele attive collidano — oggi in volo Web Hub #519, Email Hub, Blog engine, Reviews satellite, Language completeness, tutte born-green). Zero operazioni git da questa sessione: solo mockup nello scratchpad + memoria project_multichat_epic_2026_07_03 (SSoT del build, con substrato file:line) + questo log. Aggiornato SOLO il decisions-log append-only (non status.json/cantiere.json) proprio per non collidere con lo stato in scrittura da altre sessioni. Continuazione: sessione dedicata quando le altre sono chiuse, ripartendo dalla memoria. Non pushato online (Vercel 402 ~4 lug + il founder non ha chiesto push): il founder committa/pusha il BOS quando la costa è libera.

Owner: Gregorio (decisioni + timing del build) · Claude (design lock + mappatura substrato + doc).

---

Chi: Gregorio (gate founder esplicito: "applica in PROD la migration monitored_sites di #493"). Claude (verifica live prima/dopo via Supabase MCP yqhixdqipojvgzfadufo, apply_migration per il DDL, advisor security+performance, fix-alla-radice).

Cosa: applicata via MCP la migration database/migrations/2026-06-30d_web_hub_monitored_sites.sql (branch #493 feat/web-hub-monitored-sites-entity). Crea public.monitored_sites (una riga per workspace+dominio monitorato): FK workspaces(CASCADE)/external_site_audits(SET NULL)/workspace_external_integrations(SET NULL)/auth.users(SET NULL) · UNIQUE(workspace_id,domain) + CHECK domain lowercase (case-insensitive senza citext) · cadence_days 1..365 (cadenza PER-SITO, non più 7 fissi) · is_active · RLS member-SELECT / owner-INSERT-UPDATE-DELETE (idioma team_members.role='owner') · REVOKE ALL anon + REVOKE DML authenticated (scritture solo via service_role) · indice parziale WHERE is_active per il cron + trigger_set_timestamp. È il gate che sblocca in prod l'intera catena "siti monitorati nel tempo": STREAM 1 (entità + cron per-sito, #493), STREAM 2 avvisi di degrado (#498), soglia per-sito (#509), DIGEST settimanale (#518). Finché la tabella non esisteva tutto degradava fail-soft (SQLSTATE 42P01 = nessun avviso, nessun digest).

Verifica live (charter): PRIMA — tabella assente, tutti gli FK-target presenti, trigger_set_timestamp+gen_random_uuid presenti, ruoli reali = {owner, member} (nessun admin nei dati; il CHECK schema ammette owner/admin/member/viewer ma il gate usa solo 'owner' = sicuro), default-grants su tabella-peer = DML pieno a anon+authenticated (→ conferma che il REVOKE serve). DOPO — 11 colonne corrette, RLS ON + 4 policy authenticated, grants: anon=0 · authenticated=SELECT/REFERENCES/TRIGGER (DML revocato) · service_role=pieno; 4 indici (2 parziali + PK + UNIQUE), 4 FK, 2 CHECK, 1 trigger. Advisor: security = 0 nuovi (la tabella ha RLS+policy, non tocca rls_enabled_no_policy); performance = 2 INFO unindexed_foreign_keys (created_by, integration_id) + 2 INFO unused_index (tabella appena creata, 0 righe → ogni indice risulta "unused"). Decisione fix-alla-radice: NON aggiungo indici speculativi — nessuno dei due FK è su un path di query (.eq/JOIN): integration_id è solo SELEZIONATO dal cron per propagarlo all'enqueue, created_by è puro audit; l'indice aiuterebbe solo il raro scan ON DELETE SET NULL su una tabella minuscola (YAGNI), e su tabella vuota si trasformerebbe subito in un unused_index (whack-a-mole, non root fix). Coerente con 68 finding identici pre-esistenti nel DB. Il fix vero, se emergerà un filtro reale su integration_id (feature pixel-link), va nella migration che introduce quella query.

Sequencing (esplicito): applicata ORA, non in coda al merge. È additiva e sicura (tabella nuova senza dati, codice app fail-soft su 42P01, nessuna type-regen: query hand-typed). Applicarla ora de-rischia il deploy: quando la coda web-hub mergia (#493→#496→#501→#510 · #498→#509→#518) e Vercel deploya (dopo l'outage 402 ~4 lug), la tabella c'è già → nessuna finestra in cui il codice live colpisce una tabella mancante. L'effetto UTENTE parte col deploy Vercel, non con questa migration.

Owner: Gregorio (gate schema prod) · Claude (verifica live + apply + advisor + doc).

---

Chi: Gregorio (chip "costruisci l'INTERA epica Recensioni, qualità big-tech, avanzato/ultra/agentico, TUTTE e 4 le connessioni tra pianeti"; scelte via AskUserQuestion: autonomo fino in fondo · dashboard-first (vetrina sul sito = dopo) · import massivo CSV incluso · «verifica se GBP è attivo»). Claude (worktree isolato D:\Desktop\mv-reviews off origin/master 08af87d, grounding dall'audit già fatto, 6 agenti Explore paralleli + verifica avversariale su gate/PII/RLS, schema/RLS prod via MCP prima di costruire).

Cosa: il satellite web.reviews era uno stub. Ora è un motore end-to-end: feed unico multi-portale + import (incolla singola + CSV massivo RFC4180) + voto medio/distribuzione/andamento mensile/delta + bozze di risposta del Sole (Sonnet 4.6 + PII one-way + brand voice, draft-only) + avvisi (nuova recensione→campanella; insight del Sole sul calo del voto) + 4 connessioni pianeti (nuova recensione→Hub · calo→Sole · 5★→Content Studio · NPS promoter→invito recensione). ReviewsPage in 5 lingue (it/de/fr/en/es, IT non default).

2 vincoli hard rispettati: (1) gate sanità art.321 CP — sectorForbidsPublicReviews ancorato alla SSoT isRegulatedConstitution (publishingGate) + test anti-drift (blocca SOLO studio-medico/dentista/fisioterapia/psicologo, NON parrucchiere/estetica/gym; gate client+server). (2) Google GBP inerte — in prod oauth_connections+reach_google_connections VUOTE (zero connessioni; quello che il founder ricordava era la verifica GCP case 7-0288000041625, NON una connessione) → sync cablato via adapter Reach reale ma fail-soft; import manuale = path LIVE v1.

4 PR stacked (born-green LOCALE, ognuna mergiabile da sola), PUSHATE dritte su origin/master (fast-forward, branch-protection bypassata come owner) — founder "tutto in master push fai tutto tu":

• PR1 e1936de — migration web_reviews (RLS member-read/owner-write, REVOKE anon+scritture authenticated=service-role-only, UNIQUE sync idempotente, FK indicizzata) APPLICATA a prod (advisors 0-nuovi) + gate + feed + import(singolo+CSV) + computeReviewStats + ReviewsPage + swap PlanetPanel.
• PR2 9697ce0 — bozze Sole (Sonnet 4.6 + redactForExternalBoundary, nome recensore MAI al modello, draft-only su draft_reply).
• PR3 65d9830 — notifyInApp nuova recensione + insight calo voto (dedup 14g, pattern degrado Web Hub) + click-through view_reviews in AssistenteAIPage.
• PR4 b9b2c0c — 5★→Content (generate-text) + NPS promoter (feedback_responses score≥9)→invito recensione copiabile. Entrambi gate-sanità.

Verifica: born-green LOCALE (tsc src+api · vitest 51 test nuovi: stats/types/csv/alerts + gate anti-drift · eslint 0 err 444 warn<560 · knip 0 · depcruise 0 · vite build) + migration verificata live via MCP (RLS+grants+advisors) + CI master "Typecheck + build" VERDE (run 28682089291). ⚠️ install+build lentissimi su D:HDD → tracked in background.

🔴 Founder: (1) types-regen — workflow Regen Supabase Types dispatchato (run 28682110622): mergiare la PR chore che apre, per allineare types/supabase.ts a prod (la migration è già in prod → senza regen lo schema-drift gate rompe le PR future); (2) verifica live e2e quando Vercel è su (era 402 ~4 lug): incolla→feed/stats→bozza Sole→sync(inerte)→campanella/insight→amplify→Content→promoter card; (3) migliorative (→ chip comprensivo generato): PR2 path sovrano Mistral EU per bozze pubbliche · Wiring1 hardening server-gate · Wiring2 invito per-contatto+email · PR5 vetrina recensioni sul sito pubblicato (sites-runtime, 5ª connessione) · GBP live quando l'app Google è verificata.

Owner: Gregorio (decisioni) · Claude (audit-first + build 4 PR + migration+verifica live + merge a master + CI verde).

---

Chi: Gregorio (mandato "motore Blog end-to-end, qualità estrema, non manchi nulla alle PMI, ottimizza ogni articolo per l'INTERO spettro di scoperta"; 3 decisioni ratificate 2026-07-03: architettura=site_pages riuso, 2 percorsi editoriali pari, scala=tutta la Svizzera poi Europa; poi sessione /goal autonoma fino a completamento). Claude (worktree isolato D:\Desktop\mv-blog off origin/master 08af87d, grounding dall'audit già fatto, verifica schema/RLS prod via MCP prima di costruire).

Cosa: il satellite web.blog era uno stub. Ora è un motore end-to-end che RIUSA il CMS dei siti generati: un articolo = site_pages(page_type='blog-post') + 4 blocchi article-hero/body/takeaways/faq × N locale (site_block_translations) → render/sitemap/hreflang/RLS/editor arrivano GRATIS. Zero tabella blog_posts. Ottimizzato per Google + answer engine: answer-first (domanda+risposta 40-60 parole), H2/H3 semantici, statistiche con FONTE citata (magnete GEO), FAQ reali (FAQPage), BlogPosting/Article schema completo (date reali, author Person+url→fallback Org, image[] multi-ratio, mainEntityOfPage, speakable), areaServed città/cantone REALI del tenant (Local SEO canton-agnostico), CTA lead in-articolo (#506, Web→CRM→Marketing). Editoriale: 2 percorsi PARI in cabina (genera col Sole / scrivi a mano).

4 PR STACKED (born-green LOCALE, Vercel 402; scope commit planet-web):

• PR1 feat/web-blog-render (22496be, sites-runtime): 4 section-type --tenant-* + builder BlogPosting/Article + areaServed + FAQPage-da-article-faq; layout articolo nei 2 catch-all; fetch-page published_at/updated_at; fetch-blog. Fix regressione master: LeadCaptureBand (tsc rosso da quando es entrò in SiteLocale) → coercizione toLeadLocale. 30 test.
• PR2 feat/web-blog-index (d10bf59, sites-runtime): blog-index (card+filtro categorie=topic cluster+paginazione locale-aware) + CollectionPage/ItemList; llms.txt Blog leggero (llms.txt="teatro", validato mid-2026: nessun crawler AI lo consuma). 15 test.
• PR3 feat/web-blog-cabin (eef3705, app+sites-runtime): BlogCabinPage (specchio #506, editor 5 lingue, 2 percorsi pari) + useBlog (letture RLS, scritture endpoint) + apex /api/blog/manage (1 function; auth+userInWorkspace sul workspace del sito — has_planet_access è RLS-only schema private, NON RPC-callable → ownership al data layer come site-status.ts) + blog-write.ts (delete-and-recreate blocchi, cascade traduzioni, revalidateTag). Migration sites.blog_config jsonb APPLICATA A PROD (mirror lead_capture; advisor security/perf 0-nuovi).
• PR4 feat/web-blog-ai (a8db1d6, app): /api/blog/generate dispatchText sovrano (Claude EU, longform), ENV-GATED isProviderConfigured('vertex-claude-eu')→503 fail-soft (cabina resta manuale, ZERO rework all'accensione); per-locale PARALLELO (localize-non-translate, keyword locali cantone/settore da business-identity); checkTierCap('ai_text_generations', locales.length) (niente cap moltiplicati in silenzio); ledger content_generations + provenienza/ai_disclosure Art.50 in content_items(type='article'). Pseudonimizzazione PII automatica (piiGate); MAI DeepSeek/OpenRouter.

Verifica (born-green LOCALE): sites-runtime tsc+test(80)+build; multiverbe-app tsc(app+api)+test(2257)+knip+depcruise+lint(0 err, 457 warn<560)+vite build. ⚠️ vite build lentissimo su D:HDD (3-8m): lanciato tracked in background.

Decisione founder (fine sessione, via AskUserQuestion): "pusha tutto quanto e salva, qui chiudiamo" + "chip continuativo migliorativo, la produzione è vicina, dobbiamo lavorare a regime". → 4 branch PUSHATI su origin (feat/web-blog-*, no PR ancora) + chip continuativo task_9d4fee82 "Blog engine a regime: publish schedulato + estensioni".

🔴 Founder: (1) merge order dei 4 branch stacked PUSHATI (apri le PR quando sequenzi) — ⚠️ conflitti probabili con chip Web paralleli (magnet #506, locale-i18n #489/#521/#522, email hub, reviews) su PlanetPanel/fetch-page/structured-data/sitemap/llms.txt/layout; (2) post-merge verifica visiva live (seed blog-post→Rich Results + giro cabina scrivi→publish→render); (3) generazione AI dormant finché Vertex EU non provisionato (GCP_VERTEX_*); (4) follow-up onesto (→ chip task_9d4fee82): publish SCHEDULATO via content_calendar_events (job che flippa site_pages.status+revalida a data futura — piggyback su cron esistente, modalità risparmio); (5) BOS aggiornato in locale, push online quando Vercel torna.

---

Chi: Gregorio (opzione a complementare scelta al termine di STREAM 2; sul cron "la scelta migliore per Multiverbe + big-tech best practices" → delegata a Claude, "poi lavora fino a conclusione, salva e aggiorna tutto"). Claude (worktree isolato mv-web-digest, verifica schema LIVE via MCP prima di costruire).

Cosa: gli avvisi di degrado (#498) sono il canale «forte» (scattano subito su un peggioramento oltre soglia). Il digest è il complemento «calmo»: 1 volta a settimana, per ogni workspace con siti monitorati attivi, il Sole scrive UNA notifica in-app che riassume TUTTI i siti (trend del voto sintetico + 1 prossima mossa), anche gli stabili/in-miglioramento → il titolare prende l'abitudine di guardare lo stato senza dipendere solo dagli allarmi.

Decisione cron (Claude, ratificata "la migliore"): piggyback sul cron settimanale del re-audit (web-hub-reaudit, 0 4 * * 1), NON un cron dedicato. Motivi big-tech + principi Multiverbe: (1) modalità risparmio + guardrail «niente nuovi cron senza valutarne il costo» (il digest è già settimanale, la schedule esiste); (2) YAGNI/meno pezzi in movimento (un cron separato = +1 dominio d'errore + voce vercel.json + riga guardrail da tenere allineata, non giustificato dal marginale guadagno di freschezza); (3) fail-soft isolato (il pass digest in try/catch non tocca mai il re-audit che lo ospita, charter §6). Freschezza: il digest riassume lo storico completato → il re-audit lanciato stamattina entra nel digest della settimana dopo (framing "la settimana passata", corretto per un digest calmo, non un difetto).

Costruito (5 file, +678/-1, commit d52d979, ZERO migration):

• src/lib/web-hub/audit-digest.ts PURO: isoWeekKey (settimana ISO-8601 → idempotenza) + buildWeeklyDigest (riusa computeTrend/buildTrendPoints/buildSoleNextMove di STREAM 1). Ordine attention-first (cali per primi, calo maggiore in cima; miglioramenti in fondo). Cap 6 righe + coda onesta «e altri N». Copy it/de/fr/en/es. +14 test.
• api/_lib/web-hub/audit-digest-run.ts: orchestratore fail-soft (non lancia mai), workspace-scoped, service_role. Idempotente: 1 digest/workspace/settimana ISO (guardia action_payload->>period). Legge solo audit done dei workspace monitorati (filtro per workspace + match coppia in TS → niente IN gigante sui domini).
• api/cron/web-hub-reaudit.ts: piggyback best-effort (risultato nel JSON digest).
• AssistenteAIPage.tsx: nuovo action_type view_sites_digest → cabina «I miei siti».

Substrato LIVE (MCP yqhixdqipojvgzfadufo, non i file migration): ai_notifications (type/priority/category/action_type/action_payload jsonb) + external_site_audits (scores/findings jsonb + seo/ai_search/overall_score interi) in prod; monitored_sites NON ancora (#493 founder-gated) → il digest degrada fail-soft finché la tabella non esiste (come STREAM 1/2).

Verifica (born-green LOCALE, worktree mv-web-digest): tsc src+api 0 · 2034 test (+14) · eslint 0 err (0 warn file nuovi) · knip 0 · depcruise 0 (959 moduli) · vite build ok. CI required solo su PR→master → sullo stacked i gate locali = controllo. ⚠️ vite build LENTISSIMO su D:HDD a cache fredda (8m44s): lanciarlo come processo tracked in background senza & (lezione già nota di #510).

Seguito: STREAM 3 dell'epica = «multichat» (card proattiva home che aggrega avvisi + digest). Chip digest RITIRATO (fatto). Coda merge web-hub: …#493→#496→#501→#510 · #498→(#509, #518).

🔴 Founder: (1) applica monitored_sites di #493 via MCP (PERCHÉ il digest abbia siti da riassumere; prima → fail-soft, nessun digest); (2) merge #518 in coda dopo #498 (post-Vercel, 402 fino ~4 lug); (3) nessuna migration in questa PR; (4) BOS aggiornato in locale, push online quando Vercel torna.

---

Chi: Gregorio (mandato satellite Recensioni qualità big-tech connesso ai pianeti; 2 scelte via AskUserQuestion: ampiezza="genera un chip per la prossima che vada a lavorare su tutto quanto, qui aggiorna e chiudi"; connessioni pianeti="sono tutte importantissime, lavora nel chip al meglio in modo avanzato ultra ed agentico"). Claude (audit-first: 3 agenti Explore paralleli [1 morto su session-limit → gate compliance rifatto a mano] + verifica DB/RLS prod via MCP).

Audit (verificato, non ri-scoprire) — il satellite RIUSA infra già pronta: il fetch GBP delle recensioni ESISTE già reale (businessProfile.getReviews()→GbpReview[], endpoint api/reach/gbp.ts?kind=reviews, fail-soft/gated per natura); OAuth GBP provider google-business scope business.manage, token cifrati in oauth_connections; avvisi via notifyInApp→ai_notifications; bozze Sole via llmClient+routeModel('user_realtime')(Sonnet 4.6)+redactForExternalBoundary()(PII one-way)+businessIdentityPrompt(surface:'outbound'); UI template NapPage/useNapCheck (Nebula Glass). NUOVO = persistenza (web_reviews), import manuale, media/andamento, ReviewsPage, i 4 wiring. NESSUNA tabella recensioni esiste (solo design_reviews/site_legal_reviews, non pertinenti).

Gate sanità (bloccante, art. 321 CP) — recensioni pubbliche ILLEGALI SOLO per i 4 settori regolati studio-medico/dentista/fisioterapia/psicologo; ⚠️ NON tutta la macro salute (parrucchiere/estetica/gym sono legali e vogliono le recensioni). SSoT esistente regulated-compliance.ts (isRegulatedConstitution=publishingGate.requiresHumanLegalReview); sectors.privacy_warning marca ESATTAMENTE i 4 (cita "art. 321 CP", verificato via MCP). Gate client+server + helper sectorForbidsPublicReviews + test anti-drift, col messaggio che spiega il perché deontologico.

Google gated — GBP API richiede verifica app (case 7-0288000041625, OAuth in stato Test, Vercel 402): live-fetch OFF→available:false finché non verificata; import manuale = path primario v1. NON blocca l'epica. WRITE su Google differita → bozza DRAFT-ONLY (il titolare copia), non post automatico.

Piano (4 PR stacked born-green, merge=founder, scope planet-web): PR1 fondamenta (migration additiva 2026-07-03a_web_reviews.sql + gate + feed unico + import manuale + computeReviewStats media/andamento + ReviewsPage 5 lingue + swap PlanetPanel.tsx:990, Google gated off) · PR2 bozze Sole (Sonnet+PII+brand voice) · PR3 avvisi (nuova recensione + insight Sole su calo del voto, pattern STREAM 2) · PR4 wiring pianeti (amplifica 5★→Content + NPS→invito Google, entrambi gate-sanità).

Delega: chip task_bca5194c "Costruisci il satellite Recensioni (Pianeta Web)" → sessione fresca costruisce i 4 PR fino a completamento, avanzato/ultra/agentico, tutte e 4 le connessioni (founder "qui aggiorna e chiudi", contesto di questa sessione speso in audit). Grounding chip = memory project_web_reviews_satellite_epic_2026_07_03. Worktree di prep mv-reviews/branch feat/web-reviews-satellite RITIRATO (zero commit; il chip crea il suo off master). Nessun codice/DB toccato in questa sessione.

🔴 Founder: (1) avvia il chip task_bca5194c quando vuoi la build; (2) niente merge/deploy fin che Vercel 402 (fino ~4 lug); (3) nessuna migration applicata in questa sessione (la web_reviews la applica il chip in PR1); (4) BOS aggiornato in locale, push online quando Vercel torna.

---

Chi: Gregorio (mandato "il blog lavori a 360° non manchi nulla alle PMI: SEO classico + Local SEO + AEO + GEO + SXO, qualità estrema, tutta la Svizzera poi Europa"; 3 scelte via AskUserQuestion: architettura="la migliore per gli utenti" [delegata a Claude], sequenza="stack completo in una sessione /goal fresca via chip perché questo contesto è pieno", editoriale="entrambi i percorsi come pari"). Claude (audit-first 4 agenti paralleli + web-validate 2026 + verifica DB/RLS prod via MCP).

Audit (verificato, non ri-scoprire): l'infra SEO dei siti generati è già top-decile (sites-runtime/lib/seo/*: JSON-LD settore-aware, hreflang it/de/fr/en+x-default, canonical, sitemap, llms.txt, ISR, additivo-mai-inventato). Il blog è un layer ADDITIVO sottile. 2 fatti DB decisivi (prod, MCP): site_pages.page_type NON ha CHECK (solo status) → blog-post/blog-index legali SENZA migration; RLS sp/sb/sbt_public_read_published + write workspace-scoped copre già il blog (zero policy nuove); content_items.type include già 'article'.

Decisione architettura (Claude, ratificata "migliore per gli utenti"): articolo = site_pages(page_type='blog-post') + blocks + translations (rende/sitemappa/hreflanga/isola GRATIS); indice = page_type='blog-index'; ponte editoriale/provenienza AI = content_items(type='article'). NIENTE tabella blog_posts (avrebbe imposto di ri-scrivere fetch/render/sitemap/hreflang/RLS = viola "riusa non riscrivere"). Unica migration additiva prevista: sites.blog_config jsonb (mirror sites.lead_capture #506), applicata a prod in PR3.

Correzioni 2026 (web-validate, cita): "sso"=SXO (5ª disciplina, conversione nel post via fascia lead #506); llms.txt = teatro (Ahrefs: 97% domini con llms.txt valido = ZERO richieste; nessun crawler AI lo consuma; Mueller lo smentisce) → cablarlo leggero, NON investirci; FAQ rich results deprecati 7 mag 2026 + HowTo morti come feature SERP → tenere FAQPage da contenuto reale (aiuta ancora AI), niente HowTo markup; author Person+url per E-E-A-T; answer-first 40-60 parole; primi ~200 parole completi; statistiche+fonte citata = magnete GEO; dateModified reale.

Piano 4 PR stacked born-green (scope planet-web, merge=founder): PR1 render articolo+schema BlogPosting/AEO/GEO sul sito · PR2 indice+cluster+internal-linking · PR3 cabina dashboard (specchio #506, authoring manuale born-alive, sites.blog_config→prod) · PR4 generazione AI env-gated Vertex EU (fail-soft bozza manuale, per-locale localize, tier-cap, Claude EU prosa + Gemini EU strutturato).

Scala (founder): TUTTA la Svizzera (de-CH è il mercato #1, non Ticino) + Europa (en/es). Local SEO/areaServed/keyword derivati dalla località REALE del tenant, canton-agnostici, mai Ticino hardcoded; lingue dal sito, nessun default 'it'.

Delega: chip task_d74ee9f5 "Motore Blog 360°" → sessione /goal fresca costruisce i 4 PR fino a completamento (contesto di questa sessione pieno, founder "procedi, aggiorna tutto e chiudiamo qui"). Grounding chip = memory project_pianeta_web_blog_engine_2026_07_03. Worktree di prep mv-web-blog ritirato (il chip crea il suo). Nessun codice/DB toccato in questa sessione.

🔴 Founder: (1) avvia il chip task_d74ee9f5 quando vuoi la build; (2) niente merge/deploy fin che Vercel 402 (fino ~4 lug); (3) nessuna migration applicata in questa sessione (la sites.blog_config la applica il chip in PR3); (4) BOS aggiornato in locale, push online quando Vercel torna.

---

Chi: Gregorio (2 direttive via AskUserQuestion: "le PMI non conoscono 'pixel' → tutta l'app dà quello che serve senza tecnicismi, il più intuitivo possibile"; stacking su #501). Claude (worktree isolato pixel-connect, verifica DB LIVE via MCP).

Cosa: il selettore "collega il pixel" (#496) mostrava solo un hint quando il workspace ha 0 integrazioni; mancava il modo di crearne una. Nuovo pannello owner-gated "Misura le visite del tuo sito" nella cabina «I miei siti» (tra la lista monitorati e gli analytics): collega un sito (nome + indirizzo), mostra il codice mvb.js da incollare (copia + istruzioni semplici), elenca i siti collegati con stato leggibile ("in attesa dei primi dati" / "sta raccogliendo le visite" / "in pausa") e li scollega (revoke soft, con conferma). Esegue il chip task_81cae77f.

Decisione tecnica (additivo/reversibile, zero migration): riga workspace_external_integrations (generic_pixel, status pending, origine normalizzata in allowlist) via useCreateConnectedSite. Owner-gate a due livelli: UI isOwner + RLS owner/admin al data layer già presente (external_integrations_2026_05_15e, verificato live via MCP: INSERT/UPDATE owner/admin, DELETE owner; tabella vuota, 0 righe). buildMvbPixelSnippet puro (replica lo <script> del generatore server-side di #485, stack separato → consolidare al merge #485). Invalida ['web-hub-sites'] su create/revoke → il sito nuovo compare subito anche nel selettore di #496 (connette le due superfici).

Copy de-tecnicizzata in TUTTA la cabina (direttiva founder): 20 chiavi pixelConnect* nuove + riscrittura dei valori esistenti pixel*/analytics* in parole d'esito, in it/de/fr/en/es (l'italiano non è un default); nuovo test che vieta pixel/snippet/mvb.js nelle stringhe customer-facing.

Costruito: PR #510 feat/web-hub-pixel-connect (stacked su #501, commit c0125ce, 6 file +748/-51). Nuovi: src/lib/web-hub/pixel-connect.ts (+test) · src/components/web-hub/PixelConnectPanel.tsx.

Verifica (born-green LOCALE, worktree pixel-connect): tsc src+api 0 · 2025 test (+17) · eslint 0 err (0 nei file nuovi) · knip 0 · depcruise 0 (960 moduli) · vite build ok. Nessuna migration. ⚠️ Install worktree LENTISSIMO su D:HDD (killato mid-link 3× con &/timeout) → risolto lanciandolo come processo tracked in background senza &.

Seguito: chip task_62f9e17b (rifinisci il pannello: pausa/riattiva + rinomina + collega inline al sito monitorato) · allineare il comment dello snippet di #485 quando atterra. Coda merge web-hub: …#493→#496→#501→#510.

🔴 Founder: merge #510 in coda dopo #501 (post-Vercel, 402 fino ~4 lug). Nessuna migration da applicare.

---

Chi: Gregorio (proposta iniziale + decisione finale: "seguo esattamente il tuo consiglio"). Claude (ricognizione 7 lettori paralleli + panel avversariale 3 lenti: prodotto/UX, costo tecnico, business/pricing — verdetto UNANIME).

PROPOSTA INIZIALE founder (esplorata a fondo, poi corretta): (a) Booking declassato a satellite del Pianeta Web; (b) nuovo Pianeta Calendario che centralizza tutto ciò che vive nel tempo (appuntamenti Sales, contenuti da fare, marketing/social) con filtri; (c) il Calendario come luogo dove si vedono sviluppo/crescita/andamenti e si impostano gli obiettivi; scopo dichiarato: più intuitivo, "pulire il cervello", più fluido.

COSA È VERO (verificato sul codice/DB reale): il tempo è frammentato su 7+ superfici senza aggregatore (BookingDashboard settimanale, ScheduleCalendar dei post, richiamate leads.next_call_at, appuntamenti nei deal, distribuzioni Marketing suggested_time, follow-up outreach scheduled_for); esiste perfino una CalendarPage "Calendario" montata come satellite del pianeta CONTENT che mostra i meeting di SALES leggendo deals.meeting, colonna che non esiste a DB (fonte morta); gli obiettivi erano rotti/sparsi (GoalsPage→ai_goals inesistente in prod; su master già ripuntata su planet_goals con l'epic Finanza PR #458); nucleo_events (event-bus pianeti→Sole) ha 1 riga e 1 solo writer.

PERCHÉ LA RISTRUTTURAZIONE È STATA BOCCIATA (panel 3 lenti, unanime):

1. Booking → satellite Web = NO: (a) ICP capovolto — per hotel/ristorante/parrucchiere le prenotazioni SONO il business, il sito è opzionale; nello Starter Light Booking è full e il Web è ESCLUSO → satellite di un pianeta che il cliente può non avere = paradosso di pricing; (b) GTM — il pitch apre con "zero commissioni vs Treatwell 35%/Fresha 20%/TheFork": un satellite non si pitcha; il "nemico" della vision È il mondo prenotazioni-con-commissioni; (c) stato reale — Booking è il pianeta più completo (88%, 28 prenotazioni reali, ~5.400 righe + 925 SQL + 12 policy RLS hardcoded) vs Web il più sopravvalutato (68%, 6/10 satelliti vuoti); (d) precedente canon 2026-05-21 "CRM e Booking integrati, NON fusi"; il caso "Booking irrilevante per certi settori" è già risolto dalla salienza per settore (2026-06-04); (e) costo XL sul money-path (LTV CRM, ROI Marketing, Stripe webhook, growth capacity leggono bookings). Il legame Web↔Booking resta il satellite canon "widget sincronizzato nei due sensi".
2. Pianeta Calendario = NO: un pianeta-aggregatore che non produce dati propri è un secondo Sole — rompe la regola "pianeta = dominio che produce dati" e peggiora la confusione (sarebbe il 4° posto dove guardare la crescita, dopo Home agentica, KPI e Finanza). L'aggregazione cross-pianeta è il mestiere del Centro, che sul passato la fa già col Diario (/api/ai/diary, timeline normalizzata {ts, kind, planet}).

DECISIONE — percorso evolutivo "il pianeta si guadagna" (canon aggiornato: 02-product.md § Agenda del Sole + 13-mappa-prodotto.md hub a 5 funzioni):

• Fase 1 (taglia S, additiva, zero migration): AGENDA DEL SOLE = quinta funzione dell'hub AI (Chat, Memoria, Strategia, Obiettivi, Agenda). Vista calendario unificata del FUTURO, gemella del Diario: union read-only delle colonne temporali esistenti (bookings.starts_at, social_posts.scheduled_at, deals.next_activity_at, leads.next_call_at, marketing_campaigns.starts_on, follow-up outreach), filtri per pianeta, deep-link. + Obiettivi consolidati in UN posto (planet_goals, Sole ↔ Finanza; PR3 li farà pilotare il growth engine, oggi objective hardcoded {kind:'grow'}). + Bonifica CalendarPage (fonte morta; le sue 417 righe di griglia mese si riusano come shell dell'Agenda).
• Fase 2: l'Agenda scrive — creare richiamate/appuntamenti/scadenze cross-pianeta dall'Agenda (l'evento nasce lì e atterra nel pianeta giusto → inizia a produrre dati propri).
• Fase 3 (SOLO su evidenza d'uso post-dogfooding): promozione a pianeta col pattern "planned" di PLANET_CATALOG (come nacque Finanza). Booking resta pianeta in ogni scenario.
• Andamenti: NON duplicati nell'Agenda — restano Home agentica (battito) + rollup Finanza (PR4) + Galassia/Spacetime ("la storia del business nel tempo", canon da costruire: è la feature che il founder stava descrivendo).

AGGIORNATO: canon 02+13 · cantiere.json (nuovo floor ai/brain-agenda building 0% + _meta 2026-07-03) · memory project_agenda_del_sole_2026_07_03. Handoff: prompt dettagliato Fase 1 consegnato al founder per la sessione cervello. Nota operativa: prima di toccare l'app, committare il cantiere 3D corrente (branch feat/3d-web-reticolo-sfera, soffione + booking-sphere uncommitted, 61 commit dietro master).

Owner: Gregorio (decisione, commit 3D) · sessione cervello (Fase 1 Agenda) · Claude (BOS + handoff).

---

Chi: Gregorio (decisioni · territorio 3D founder). Claude (2 chip coordinati: APP task_537a9f79 = questa connessione · MOTION task_9906eabd = fisica del soffio).

COSA: il Pianeta Marketing 3D (il soffione/dente di leone, validato nel banco ?inspect=marketing-lab) passa da prototipo a collegato all'app reale: quando parte una campagna, il soffione "soffia" i semi (reach); tornando al pianeta è di nuovo pieno. È il primo pianeta che consuma eventi reali dell'app — coerente con l'architettura "i pianeti emettono/consumano eventi" (Hub Messaggi CRM).

3 DECISIONI founder (al bivio, AskUserQuestion):

1. Evento sorgente = launch + newsletter + ads: il soffio parte da TUTTE le superfici campagna — distribuzione "Ho pubblicato", newsletter inviata, "Lancia negli Ads". (Scartato: solo-launch; completamento — richiederebbe modellare uno stato "completata" oggi assente.)
2. Impostazione "soffia per confermare la campagna" = GESTO: opzione (default OFF, per-dispositivo) per cui confermare una campagna diventa un gesto — tieni premuto e "soffi" sul pulsante per rilasciare i semi = il soffio È la conferma d'invio. Vive in Impostazioni → Preferenze.
3. Ripristino = TRANSIENTE, non persistente: il soffio è una celebrazione al lancio; lo stato a riposo è SEMPRE pieno e rientrando nel pianeta si ripristina. Niente deplezione per-tenant persistita (evento nello store non-persistito, si azzera al remount/reload).

COSTRUITO (additivo · gate verdi tsc/lint/knip/build · verificato live nella scena di produzione /3d-preview: soffione cottony montato accanto al Sole e agli altri pianeti, apertura su selezione funzionante):

• Backbone eventi (store transiente marketingBlowNonce + wiring 3 superfici + impostazione localStorage + gesto BlowToConfirmButton).
• Mount in produzione: il Pianeta Marketing usa il soffione (DandelionEye), gli altri 5 pianeti INVARIATI. Apertura legata alla selezione. Consuma l'evento → soffio one-shot → torna pieno.
• I 2 chip sono CONVERGENTI: API buildSeedLayer.update(t, open, detach) stabile; il MOTION disegna la fisica vortex-ring, l'APP la cabla.

STATO: codice app LOCAL/uncommitted sul branch feat/3d-web-reticolo-sfera (cost-mode · il founder committa). Il founder rifinisce look/motion dal vivo (l'esposizione headless non mostra il moto). Memory: project_3d_marketing_dandelion_2026_07_02.

Owner: Gregorio (conferma look live, commit app) · Claude (codice, coordinamento chip).

---

Chi: Gregorio ("lavora qui su 1-2 task, il resto chip, poi BOS + chiudi · estrema qualità big-tech · i chip devono vedere il lavoro in corso"). Claude (worktree mv-web-degrade riusato, coordinato con la sessione multichat concorrente).

Cosa: STREAM 2 (#498) avvisa quando un sito monitorato peggiora oltre una soglia FISSA (8 punti). Questa PR la rende regolabile per-sito dal titolare — 3 preset: "solo cali importanti" (15) · "bilanciata" (8, = il default storico) · "anche cali piccoli" (5). Esegue l'opzione B messa in pausa nel menu di v203.

Decisione tecnica (additivo/reversibile, migration GATED): colonna monitored_sites.alert_min_drop int DEFAULT 8 CHECK 3..50 → default = comportamento attuale, ZERO regressione. decideAuditAlert accettava GIÀ le soglie come 3° argomento (architettura pronta apposta): la logica PURA aggiunge solo il mapping preset↔soglia (sensitivityToMinDrop/minDropToSensitivity/clampMinDrop). audit-degradation.ts legge la soglia e la passa; fail-soft su 42703 (colonna assente → default 8) così STREAM 2 non regredisce se la migration lagga. monitor.ts accetta alertMinDrop (owner-gated); sites.ts la ritorna (42703-robust); UI SensitivityControl (select owner+monitorato) in TrackedSitesList, copy in 5 lingue.

Coordinamento (founder "i chip devono vedere il lavoro in corso"): scelto DELIBERATAMENTE il task a zero overlap con la multichat (altra sessione, memory project_multichat_proactive_card_2026_07_01): la multichat tocca notifiche/AssistenteAIPage/deep-link/BELL_EVENTS, il per-sito tocca solo audit-alert/degradation/monitor/sites/TrackedSitesList/cockpit-i18n. Di conseguenza il chip deep-link click→trend è stato RITIRATO (assorbito dalla PR3 multichat che gestisce TUTTI i deep-link notifiche). Resta chip solo il digest settimanale (task_52014f11) — ⚠️ da rivalutare: la card multichat (daily-brief + feed) potrebbe già sussumerlo.

Costruito (PR #509, feat/web-hub-alert-threshold-per-site, stacked su #498, commit 465e828, 11 file +283/-23): migration + audit-alert.ts(+6 test) + audit-degradation.ts + monitor.ts + sites.ts + tracked-sites.ts + cockpit-i18n.ts + TrackedSitesList.tsx + useTrackedSites.ts.

Verifica (born-green LOCALE): tsc src+api 0 · 2026 test (+6) · eslint 0 err · knip 0 · depcruise 0 (956 moduli) · vite build ok. ⚠️ D:HDD molto contesa (graphify rebuild + sessioni concorrenti) → gate lenti ma verdi.

🔴 Founder: applica 2026-07-02_web_hub_alert_threshold_per_site.sql DOPO 2026-06-30d (monitored_sites di #493) + merge in coda dopo #498 → #509. Giro reale a Vercel su (402 fino ~4 lug).

---

Chi: Gregorio (accessi GCP + correzione email). Claude (esecuzione quota via Chrome MCP, merge PR, memoria).

MILESTONE — quota EU multi-region COMPLETA (esecuzione di v202): tutte 6/6 le righe filate sul progetto GCP multiverbe-2606030125, endpoint eu multi-region, base_model bare (anthropic-claude-sonnet/anthropic-claude-opus). Valori launch-tier: Sonnet input 500K / output 150K / requests 100 · Opus input 300K / output 100K / requests 50. Ogni aumento >0 → co-approvazione Anthropic (latenza giorni) + email conferma. ⚠️ Trappola: il bare base_model esiste per US + EU + Global → filate SOLO le "EU multi-region" (verificato nel pannello prima di ogni invio).

Merge: #507 (client_copy Fase 1) + #508 (fix rottura CI repo-wide: Semgrep Community rule github-actions-mutable-action-tag promossa a WARNING bloccava OGNI merge → pin 11 action a commit-SHA su 7 workflow) su master. Master verde (unico required check = "Typecheck + build").

CORREZIONE (founder, enfatica): email UFFICIALE Multiverbe = info@multiverbe.com (+ tel svizzero 0783291245), NON metaverbe@gmail.com (= solo login personale GCP). Il campo Email del form quota GCP è non-editabile (= account loggato), quindi le notifiche del case arrivano a metaverbe@gmail.com; non intacca la validità delle quote.

Stato: go-live = BLOCK 3, gated su co-approvazione Anthropic (giorni) → env GCP_VERTEX_CLAUDE_MODEL=claude-sonnet-5 + GCP_VERTEX_OPUS_MODEL=claude-opus-4-8 + micro-modifica adapter → host multi-region (aiplatform.eu.rep.googleapis.com//locations/eu/, Claude-only, Gemini invariato) + flip AGENT_COPY_LLM + merge #473 + BRAIN_EU_VERTEX=1 (cervello EU = fine Anthropic-diretto). Da fare in sessione fresca (contesto). Aperti founder-side: Vercel account bloccato (billing) + schema-drift booking_channels. Memory: project_sonnet5_vertex_eu_2026_07_01.

Owner: Gregorio (accessi, go-live) · Claude (codice BLOCK 3 in sessione fresca).

---

Chi: Gregorio (delega + accessi Google/GCP). Claude (esecuzione follow-up: decisione endpoint delegata, quota filing via Console GCP, PR client_copy).

CONTESTO: continua v201, che aveva lasciato aperti due item — endpoint Vertex EU e quota. Questa entry li risolve e shippa la Fase 1 del client_copy.

DECISIONE 4 — Endpoint Vertex EU = eu MULTI-REGION (scelta delegata a Claude). I due endpoint EU espongono schemi base_model diversi: (a) europe-west1 regionale = base_model VERSIONATO (anthropic-claude-sonnet-5), NON self-serve — le righe non si materializzano in IAM→Quote nemmeno dopo smoke test; (b) eu multi-region (aiplatform.eu.rep.googleapis.com, location eu) = base_model BARE (anthropic-claude-sonnet/anthropic-claude-opus), self-serve + adjustable subito. Scelto multi-region: future-proof (i nuovi Claude atterrano lì per primi, bucket bare stabili anche per modelli futuri), più resiliente, stesso prezzo (+10% vs global, già pagato oggi). Trade-off: micro-modifica adapter Claude-only in BLOCK 3 (host aiplatform.eu.rep.googleapis.com + path /locations/eu/). CH-only NON è opzione per Claude-su-Vertex (Zurich europe-west6 senza modelli Anthropic) → residenza CH del LLM = tema separato (piano uscita).

QUOTA multi-region — filing avviato: schema risolto (base_model BARE, metriche eu_multi_region_online_prediction_{requests,input_tokens,output_tokens}_per_base_model). 6 righe da alzare: Opus (anthropic-claude-opus) req 50 / input 300K / output 100K · Sonnet (anthropic-claude-sonnet) req 100 / input 500K / output 150K. 1/6 inviata (Opus input 300K, req ID 9f2389f3-9258-4148-a6e1-ee997ef2ab5a), 5 in coda (form identici). Ogni aumento >0 → co-approvazione Anthropic (latenza giorni, email conferma → metaverbe@gmail.com). Quota = rate-limit (token/min, req/min), NON soldi (billing a consumo separato, 0 CHF finora).

client_copy Fase 1 — shipped come PR #507 (feat/client-copy-worldclass-sonnet5, commit 41fc9fb, verso master). Ladder per-tier: Starter=Mistral Large 3 · Pro=Sonnet 5 (effort) · Business=Sonnet 5 draft → Opus 4.8 editor → giudice Opus su email/broadcast. Fail-open + gated AGENT_COPY_LLM (OFF al merge). Nuovo provider vertex-claude-opus-eu + purpose client_copy_edit/client_copy_judge + resolveVertexClaudeModel (lever go-live). Gate locali verdi (1943 test / lint 0-err / knip 0 / depcruise 0-nuove / build). Claude-path non verificabili live finché quota=0 → fallback Mistral/Gemini coperto da test. PR2 = grounding brand-voice pgvector (deferito).

Stato: endpoint deciso ✅ · quota 1/6 filed + 5 in coda (co-approvazione Anthropic, giorni) · PR #507 aperta (CI in corso, squash-merge SOLO su conferma founder). Go-live BLOCK 3 (a quota concessa) = env GCP_VERTEX_CLAUDE_MODEL=claude-sonnet-5 + GCP_VERTEX_OPUS_MODEL=claude-opus-4-8 + adapter → multi-region host + flip AGENT_COPY_LLM. Poi merge PR #473 + BRAIN_EU_VERTEX=1 (cervello del Sole su Vertex EU = fine Anthropic-diretto). Memory: project_sonnet5_vertex_eu_2026_07_01.

Owner: Gregorio (accessi, importi quota) · Claude (esecuzione).

---

Chi: Gregorio (opzione via AskUserQuestion: "1 + chip per il resto"). Claude (verifica DB LIVE via MCP → build born-green, worktree isolato pixel-link).

Cosa: STREAM 1 (#493) ha reso i siti monitorati un'entità con integration_id, ma mancava il modo di valorizzarlo e di vederne i frutti. #496: selettore "Collega il pixel" (solo owner) che aggancia un sito monitorato alla sua integrazione mvb.js. #501: pannello "Il tuo pixel" (visite, persone uniche, pagine/eventi top + snippet da copiare) nella cabina «I miei siti».

Decisione tecnica (additivo/reversibile, zero migration): #496 — GET /api/web-hub/sites espone le integrazioni pixel (generic_pixel, stati collegabili, MAI api_key_hash/prefix) + integration_id per sito; picker owner-gated accanto alla cadenza + badge "Pixel collegato"; IDOR chiuso in monitor.ts (valida che integrationId sia del workspace: il FK garantiva solo l'esistenza, non la proprietà). #501 — pannello che fetcha GET /api/web-hub/analytics (endpoint dello stack #485) senza importarlo (contratto ridefinito in src/lib/web-hub/pixel-analytics.ts, come SitesResponse); 404/503 → silenzioso (si accende da solo quando i dati arrivano). Copy 6+12 chiavi in it/de/fr/en/es (l'italiano non è un default).

⚠️ Scoperta (impatta la coda merge): l'analytics UI sta all'INCROCIO di due stack non-merged — la cabina MySitesPage vive nello stack #468→#493, l'endpoint dati vive nello stack separato #485 (feat/web-hub-pixel, base master). Quindi #501 ha una dipendenza a runtime da #485: il pannello mostra dati solo quando #485 è deployato.

Costruito: #496 feat/web-hub-monitored-pixel-link (stacked su #493, commit ed3548c, 8 file +331/-16) · #501 feat/web-hub-pixel-analytics-ui (stacked su #496, commit fc68fad, 6 file). workspace_external_integrations verificata via MCP: esiste da MAGGIO (external_integrations_2026_05_15e, non da #485), vuota in prod (0 righe); monitored_sites (#493) non ancora applicata → tutto fail-soft.

Verifica (born-green LOCALE, worktree pixel-link): tsc src+api 0 · 2015 test · eslint 0 err (0 nei file nuovi) · knip 0 · depcruise 0 · vite build ok. Nessuna migration.

Follow-up chips (founder "1 + chip per il resto"): flusso "connetti un nuovo pixel" task_81cae77f (crea la riga workspace_external_integrations dalla dashboard; oggi 0 pixel = solo hint) · prossima lacuna Pianeta Web task_98403c6c (satelliti vuoti / multilingua-senza-wizard). Memory project_web_hub_pixel_link_2026_07_01.

🔴 Founder: merge in coda …#493 → #496 → #501 + lo stack #485 perché il pannello mostri dati. Applica la migration monitored_sites di #493 (prima → fail-soft, selettore vuoto). Giro reale a Vercel su (402 fino ~4 lug).

---

Chi: Gregorio (scopo via AskUserQuestion + mandato "raffina come una bigtech, aiutami a scegliere"). Claude (verifica substrato LIVE via MCP → build born-green, worktree isolato mv-web-degrade).

Cosa: STREAM 1 (#493) ha reso i siti monitorati un'entità con cadenza + il cron di re-audit; mancava il «so what» — nessuno avvisava il titolare quando un sito monitorato peggiora. Ora: quando un re-audit di un sito monitorato chiude e il voto SEO o Ricerca AI scende oltre soglia rispetto all'ultimo controllo completato, il Sole scrive una notifica in-app (warning) col delta + la prossima mossa.

Decisioni founder (AskUserQuestion 2026-07-01): Forma = avviso di degrado azionabile (Opzione 1; scartati digest settimanale e task-system come follow-up). Sensibilità = founder "aiutami a scegliere come una bigtech" → Claude sceglie soglia fissa di qualità: avvisa se SEO o Ricerca AI scende ≥ 8 punti/100; grave (priority high) se ≥ 15. Tarata affidabile-prima-che-tempestiva (regola #1 del proactive alerting: mai gridare al lupo). Override per-sito = follow-up additivo (soglia = costante nominata, niente refactor).

Decisione tecnica (additivo/reversibile, migration-free): logica PURA decideAuditAlert (dedup naturale = confronto vs l'audit done immediatamente precedente → un voto basso ma stabile non ri-avvisa, scatta solo su un calo nuovo/più profondo) + copy buildDegradationNotification in it/de/fr/en/es. Orchestratore api fail-soft (non lancia mai): monitored-check (42P01-soft, monitored_sites non ancora in prod) → confronto → idempotenza su action_payload.audit_id (ri-consegna QStash safe) → notifyInApp. Riusa buildSoleNextMove di STREAM 1 (prossima mossa già localizzata). Wiring nei due path di persistenza: worker QStash (re-audit cron) + audit sync. Nessun nuovo canale, nessun toggle: l'avviso è raro + opt-in (solo siti che il titolare monitora) → le quiet-hours già lo coprono (modalità risparmio).

Costruito (PR #498, feat/web-hub-degradation-alerts, stacked su #493, commit 9329c98, 5 file +508): src/lib/web-hub/audit-alert.ts (+15 test) + api/_lib/web-hub/audit-degradation.ts + wiring worker.ts/audit.ts. Commit 2 (2b049d4): il click della notifica (action_type: view_site_audit) apre la cabina «I miei siti» (satellite Web·site, sequenza openPlaySurface) → completa il click-through azionabile. Follow-up chips (founder "il resto + migliorativo"): soglia per-sito task_a97295d9 · digest settimanale task_fcff7ab2 · deep-link click→trend del dominio task_04464e17.

Verifica (born-green LOCALE, worktree mv-web-degrade): tsc src+api 0 · 2020 test (+15) · eslint 0 err · knip 0 · depcruise 0 (956 moduli) · vite build ok. Nessuna migration. CI required gira solo su PR→master → su stacked i gate locali sono il controllo.

🔴 DA FARE / epica futura (founder 2026-07-01: "segnare su BOS assolutamente"):

• [ ] STREAM 3 = "multichat": una card fissa proattiva in cima alla home, SOPRA il sistema solare, dove Multiverbe avvisa di TUTTE le news e propone azioni da rendere auto/semi-auto parlandoci ("lui è il tutto dell'app"). È il livello di orchestrazione/conversazione SOPRA gli eventi ai_notifications — STREAM 2 ne è il primo feed. Chip task_5045c8b8 creato col mandato di fare domande al founder prima di costruire. Memory project_multichat_proactive_card_2026_07_01.

🔴 Founder: applica la migration monitored_sites di #493 (perché l'avviso scatti; prima → fail-soft, nessun avviso) + merge in coda dopo #493 → #498. Giro reale a Vercel su (402 fino ~4 lug).

---

Chi: Gregorio (follow-up #489 spagnolo, decisioni via AskUserQuestion). Claude (refactor tipi born-green, worktree isolato mv-locale-es-followup).

Cosa: chiusura del debito IT-only residuo nei tipi advisory del site-design, lasciato fuori da #489 per tenerla piccola. de/fr/en/es generano già correttamente (la lingua di output è governata da SystemPromptContext.targetLocale): questa PR rende onesti i tipi, non cambia comportamento.

Decisione tecnica (additivo/reversibile, zero migration):

• LanguageGrade ('italian-A2'..'italian-C1', misnomer: era un livello di leggibilità, non una lingua) → ReadingLevel CEFR puro ('A2'..'C1'); campo BrandDNA/CopyDirectives.language → readingLevel.
• LocalCROAdjustments.multilingual: primary: 'it' (literal) → SiteLocale; secondary → SiteLocale[] (write-only, zero reader; coerente con "IT non è un default" v200).
• Consumer: stage-1 (ternario no-op it?B2:B2 → readingLevel: 'B2'; param orfano → _primaryLocale riservato), menu-showcase (prompt Lingua: italian-B2 → Leggibilità (CEFR)), 8 constitution (readingLevel: 'B2').

Decisioni founder (AskUserQuestion 2026-07-01): Q1 readingLevel CEFR puro · Q2 multilingual = SiteLocale · Q3 keyword SEO es rimandate.

Verifica (born-green LOCALE): tsc src+api · 1940 test · eslint 0 err · knip 0 · depcruise 0 · vite build ok. Nessuna migration.

🔴 DA FARE / rimandato (senza dimenticarlo):

• [ ] Keyword SEO spagnole in seoKeywordsToInclude delle 8 constitution (frontend/multiverbe-app/src/lib/site-design/constitutions/*.ts): rimandate perché il campo è advisory e oggi non ha alcun reader (effetto runtime nullo). Si aggiungono quando il campo verrà letto da una pipeline, mirate per settore (mercato ispanofono CH: ospitalità/città turistiche). Decisione founder Q3.
• [ ] Giro reale es end-to-end (item 1 del follow-up #489, richiede Vercel su ~3-4 lug): sito con es in availableLocales → INSERT sites ok (CHECK già allargata in prod) → Stage 3 scrive site_block_translations locale='es' → servito su <sub>.multiverbe.app/es/ con chrome ES + hreflang es-CH/og:locale es_CH → opzionale visibility-check locale:'es'. Checklist completa nel commento di PR Multiverbe#497.

🔴 Founder: merge #497 in coda dopo #482→#489 (post-Vercel).

---

Chi: Gregorio (decisioni via chat + accessi Google/GCP). Claude (esecuzione: Console GCP via browser, smoke test Cloud Shell, diagnosi stack).

CONTESTO: Claude Sonnet 5 rilasciato 2026-06-30 (claude-sonnet-5). Prezzo intro $2/$10 per 1M (fino 31 ago) → poi $3/$15 = stesso di Sonnet 4.6 ma qualità ≈ Opus 4.8 sui task agentici. Obiettivo: portare tutto lo stack LLM Claude su Vertex EU con Sonnet 5 (EU Data Boundary) → eliminare Anthropic-diretto (US).

DECISIONE 1 — Adottare Sonnet 5, tutto su Vertex EU. Abilitati su Vertex Model Garden (progetto GCP multiverbe-2606030125, org Multiverbe, billing account founder — la Sagl NON serve per usare/quota): claude-sonnet-5 + claude-opus-4-8 (judge + strategico). ToS Anthropic+Google Marketplace accettati a nome founder (contrae lui come persona finché non c'è la Sagl). Sonnet 4.6 NON abilitato (reso inutile da Sonnet 5). ⚠️ Scoperto che la rotta Claude-su-Vertex non era MAI stata attivata → il gateway prod ripiegava silenziosamente su Gemini.

DECISIONE 2 — Mistral resta DIRETTO (Mistral-FR, ZDR+DPA), NON su Vertex (pur essendo disponibile su Vertex). Motivo founder: ZDR/GDPR sull'outreach (dati prospect) + "una cosa in meno". Verbatim: "mistral è l'unico altro modello che usiamo a parte, manteniamolo diretto per essere sicuri." Copre: outreach/cold-email (sales, tutti i tier) + client_copy primario Starter/Pro.

DECISIONE 3 — client_copy "world-class" ladder (R2 tier-quality): Starter=Mistral Medium 3 (FR/ZDR) · Pro=Sonnet 5 (Vertex EU, effort medium→high) · Business=Sonnet 5 draft → Opus 4.8 editor (2 passaggi) + judge gate Opus sul copy alto-rischio, effort high→xhigh. Moltiplicatori qualità (più del modello): draft→critica→riscrittura, grounding brand-voice per-tenant (pgvector)+skill multiverbe-copy+resolveMarketContext, judge gate pre-azione, eval-set che gata i cambi. Da costruire (PR, codice, no quota needed).

BLOCCO — Quota Vertex = 0: Sonnet 5 e Opus 4.8 abilitati ma quota=0 su TUTTI gli endpoint (europe-west1/eu/global) → 429 RESOURCE_EXHAUSTED. Quota = rate-limit (token/min, req/min), NON soldi (billing separato a consumo, 0 CHF finora). Serve richiesta di aumento = gate, con latenza di provisioning Google (la riga self-serve di anthropic-claude-sonnet-5 non ancora esposta in IAM→Quote; quella di claude-fable sì). Inviabile ORA senza Sagl. Importi consigliati (launch-tier, ri-alzabili): Sonnet 5 = 100 req/min · 500K input · 150K output tok/min; Opus 4.8 = 50 · 300K · 100K.

Stato: enabling ✅ · quota pending (founder conferma importi + attende provisioning riga) · client_copy da costruire · go-live = env GCP_VERTEX_CLAUDE_MODEL=claude-sonnet-5 (accende gateway sovrano già in master) + merge PR #473 (feat/eu-claude-brain-vertex, dormiente, ~57 dietro master) + BRAIN_EU_VERTEX=1 (cervello del Sole su Vertex EU = fine Anthropic-diretto). Chip sessione migliorativa spawnato (task_89981bc1) per completare quota→PR client_copy→go-live. Caveat charter: tokenizer Sonnet 5 nuovo (~1.0-1.35×) → ri-baseline caching; cyber-safeguard ON → monitora refusal falsi-positivi. Memory: project_sonnet5_vertex_eu_2026_07_01.

Owner: Gregorio (decisioni, importi quota, accessi) · Claude (esecuzione via chip).

---

Chi: Gregorio (STREAM 1 epica External Site Hub, mandato big-tech + "lingue tutte pari"). Claude (verifica schema LIVE via MCP → build born-green).

Cosa: i "siti monitorati" erano un set DERIVATO (ogni dominio con un audit done ri-controllato dal cron a 7 giorni fissi). Mancava la distinzione fra i siti PROPRI da tenere d'occhio nel tempo e i check una-tantum di concorrenti/siti altrui (che NON vanno ri-controllati: spreco di quota PSI/CrUX + sorpresa). Ora il monitoraggio è una scelta esplicita con cadenza per-sito.

Decisione tecnica (additivo/reversibile, gate founder solo sulla migration): nuova tabella monitored_sites (interruttore is_active + cadence_days, FK a external_site_audits/integrazione pixel, UNIQUE per workspace+dominio, RLS member-read/owner-write come planet_setups, REVOKE anon+authenticated DML). API POST /api/web-hub/sites/monitor owner-gated al data layer + GET arricchito (isMonitored+cadenza+locale). Cron ripuntato sui monitorati attivi con cadenza per-sito. UI interruttore "Monitora" (solo owner) + badge monitorato/una-tantum. Tutta la copy della cabina ora in 5 lingue (era IT-only di #468/#481). Fail-soft su tabella assente (SQLSTATE 42P01) → deploy verde pre-migration.

Costruito (PR #493, feat/web-hub-monitored-sites-entity, stacked su #486, commit e9d2bfe, 12 file +1363/-181): migration 2026-06-30d_web_hub_monitored_sites.sql (GATED) + monitor.ts/sites.ts/audit-access.ts(nuovo assertWorkspaceOwner) + cron selectMonitoredDueForReaudit puro + TrackedSitesList/MySitesPage/useMonitorSite + catalogo cockpit-i18n 5 lingue.

Verifica (born-green LOCALE, worktree isolato mv-web-monitored): tsc src+api · 2005 test · eslint 0 err · knip 0 · depcruise 0 · vite build ok. Schema LIVE verificato via MCP PRIMA (FK targets esistono, role enum owner/member, grants default, owner-gate idiom). Migration NON applicata (gate founder). Giro reale a Vercel su (402 fino ~3-4 lug).

Lezione: per una colonna gestionale su tabella nuova → REVOKE esplicito anon+authenticated (Supabase concede DML pieno di default, verificato su external_site_audits) + gate ruolo al data layer (assertWorkspaceOwner) oltre alla RLS (la RLS da sola non basta, charter §5). Owner-only perché monitorare è scelta gestionale, non operativa. Stream 1 di 4 dell'epica External Site Hub.

🔴 Founder: applica 2026-06-30d via MCP + merge in coda #468→#474→#478→#481→#486→#493.

---

Chi: Gregorio (mandato lingua "lingue tutte pari" 2026-06-30 esteso al Pianeta Web; menu di prosecuzione "1+2" poi "2+4+chip"). Claude (verifica stato reale DB+codice → fix alla radice born-green).

Cosa: il site builder (siti generati) e due subsystem adiacenti del Pianeta Web (reach AI-visibility, widget embeddabile) gateavano la lingua a 4 valori (it/de/fr/en) → un sito / una traduzione / un check in spagnolo falliva. Esegue il chip task_124e3526 captato in v199 (es nei siti generati, tenuto fuori da #486 per non confliggere col wizard #482, ora MERGEABLE).

Scoperta chiave: il blocco vero NON erano i tipi TS ma 5 CHECK del DB che rifiutavano es all'INSERT (il "sito es rotto" nella forma più dura: l'insert fallisce, non un fallback). E workspaces.primary_language ammetteva già es (CHECK a 5 valori) → il layer azienda precedeva il builder, conferma che il builder era in ritardo.

Decisione tecnica (no AskUserQuestion: codice + schema additivo/reversibile, mandato founder esplicito): allargare le CHECK ALLA RADICE + completare ogni Record<Locale>/allowlist/switch a 5 lingue, con traduzioni spagnole reali (formali "usted", anti-slop) per tutto il chrome customer-facing. Gap-2: default lingua del wizard derivato da workspaces.primary_language (precedenza pickWorkspaceLocale), non hard 'it' → raffina la non-preselezione-totale di #482 (commit2) in default-intelligente-dall'azienda (sempre cambiabile, mai IT-by-fiat; revert = 1 file se il founder preferisce la non-preselezione pura).

Costruito (PR #489, feat/site-builder-locale-es, stacked su #482, 3 commit): 2 migration applicate+verificate in prod — 2026-06-30_site_builder_locale_es (sites.default_locale + sites.available_locales + site_block_translations.locale) e 2026-06-30b_reach_widget_locale_es (ai_visibility_checks.locale + external_widget_configs.forced_locale). c1: SiteLocale+LocalizedString, start.ts, copywriter persona+cliché ES, sites-runtime (allowlist middleware+route+layout, hreflang es-CH/og es_CH, chrome ES in i18n.ts ~55 stringhe + nav + cookie banner + footer). c2: useWorkspace.primaryLanguage + SiteBuilderWizard semina via normalizeSiteLocale. c3: reach Perplexity Sonar prompt ES + Zod enum + tipi client; widget DB-only (forced_locale è string).

Verifica (born-green LOCALE, worktree isolato): multiverbe-app tsc app+api + vitest (1940 pass) + eslint (0 err) + knip (0) + depcruise (0) + vite build verdi; sites-runtime tsc + vitest (23) + eslint (0 err) + next build verdi. DB: 5 CHECK allargate, es_site_ok=true. Niente giro reale di generazione (serve pipeline LLM+worker+Vercel, giù 402 fino 3 lug) → chip task_58958214 (giro reale post-Vercel + generalizzare gli advisory IT-only LanguageGrade/LocalCROAdjustments.multilingual.secondary). Ordine merge: …→#482→#489 (founder, a Vercel ripristinato).

Lezione: il gate nascosto delle lingue è il DB CHECK, non i tipi (de/fr/en passavano i tipi ma 'es' falliva l'INSERT) → per "aggiungere una lingua" cerca SEMPRE i CHECK locale in prod (pg_constraint) prima del codice. Su D: HDD sotto contesa I/O il vite build si impalla e 2>&1|tail non flusha (sembra appeso) → pnpm exec vite build da solo (senza il tsc && già verde) chiude in ~20s.

---

Chi: Gregorio (mandato lingua, correzione 2026-06-30: ogni stringa customer-facing in it/de/fr/en/es, l'italiano NON e' un default ma solo la lingua per parlare col founder). Claude (verifica stato reale → fix alla radice born-green).

Cosa: il motore audit del Web Hub (#457) e la "prossima mossa" del Sole (Fase 5, #481) producevano i testi rivolti all'utente (findings title/why/how + evidence; headline del Sole) SOLO in italiano → per ogni tenant non italofono (la CH e' multilingue) erano stringhe rotte, lacuna nota di #457/#481. Sanata: il motore RILEVA, il TESTO vive in un catalogo per id stabile × 5 lingue scelto dalla lingua del workspace (pattern gemello di CRM_STRINGS in sole-crm).

Decisione tecnica (no AskUserQuestion: codice puro, no schema/canon/costo): localizzare ALLA RADICE (catalogo per id), non bolt-on a valle. Catalogo in src/ (non api/) cosi lo importano sia il motore api/ sia il Sole src/ (api→src permesso, src→api vietato da dep-cruiser). Lingua fuori catalogo → en (fallback internazionale neutro, NON IT). Locale del workspace da primary_language>language (pickWorkspaceLocale).

Commit 2 (AI-polish opzionale, scelta founder "1+2" nel menu di prosecuzione) a6ac9c0: api/_lib/web-hub/sole-polish.ts rifrasa la sola headline della prossima mossa nella VOCE del brand + lingua del workspace (llmClient.complete single-shot + buildBusinessIdentity). Env-gated WEB_HUB_SOLE_AI_POLISH=1, default OFF → costo ZERO (decisione di costo, modalita' risparmio: i deterministici bastano da soli). Cost-aware: cache per (auditId,locale) in signals.solePolish (write-back) → il modello gira max una volta per audit, non a ogni page-load. Fallback deterministico + anti-slop. 6 test puri.

Costruito (PR #486, feat/web-hub-findings-i18n, stacked su #481, 13 file +1437/-344): catalogo src/lib/web-hub/audit/findings-i18n.ts (22 id × 5 lingue + lab-slow + evidence/numeri per locale + nextMoveStrings + normalizeAuditLocale, completezza a compile-time via Record su unione esatta) · buildFindings(page,probe,locale,perf?) pesca dal catalogo · run.ts passa la lingua ai 2 ingressi · resolveWorkspaceAuditLocale cablata ai 4 consumer (route singola, worker QStash, fallback inline /start, sole-suggestions) · buildSoleNextMove({…,locale}) (rimosso toLowerCase che rompeva i nomi tedeschi) · test completezza+localizzazione (+18).

Verifica (born-green LOCALE, worktree isolato · entrambi i commit): tsc src+api + vitest (1995 pass, +24, 0 regressioni) + eslint (0 errori) + knip (0) + depcruise (0 violazioni) + vite build tutti verdi. Commit 8914c15 (deterministico) + a6ac9c0 (AI-polish). external_site_audits = 0 righe prod (MCP) → zero migration, zero impatto dati. CI required gira solo su PR→master → gate locali = controllo. Ordine merge: #468→#474→#478→#481→#486 (founder, a Vercel ripristinato).

Stream 3 (es nei siti generati) = chip task_124e3526, NON in #486: verificato che lo spagnolo end-to-end e' cross-repo (non un tweak del wizard #482): SiteLocale canonico in src/lib/site-design/types.ts + sites-runtime ([locale] route + lib/sections/i18n.ts) + LanguageGrade italian-only; il wizard #482 (concorrente, MERGEABLE) fa solo it/de/fr/en e preseleziona IT (default da rendere workspace-driven). Captato come chip per non rushare/confliggere col branch concorrente. Stream 1 (monitored_sites esplicita) resta, serve migration founder.

Lezione: security/detect-object-injection scatta anche su Record<Union>[unionVar] (warning sotto soglia ma il charter vuole il fix → disable mirato documentato). Types solo-interni non esportati (Knip). satisfies da solo basta per keyof literale (no as const).

---

Chi: Gregorio (epica "siti monitorati": far vivere un sito esterno dentro l'ecosistema nel tempo, non piu' uno scatto singolo · 3 decisioni via AskUserQuestion). Claude (verifica stato reale DB+PR+codice → plan-first → build born-green + giro gate locali completo).

Cosa: la cabina "I miei siti" del Pianeta Web finora faceva un audit one-shot (l'engine multipagina #478 e la UI #468/#474 erano gia' pronti ma APERTI/non mergiati). Questa PR aggiunge lo strato temporale: ogni sito analizzato diventa una proprieta' tracciata con storico dei voti, trend (sale/scende), ri-controllo a comando e automatico, e il Sole che dall'ultimo audit ricava la "prossima mossa". Lo storico esisteva gia' nei dati (una riga external_site_audits per controllo) ma non era esposto → tutto derivato, zero migration.

Stato reale verificato PRIMA di costruire (charter): external_site_audits 0 righe in prod (Vercel giu' + feature mai esercitata live → trend gestito con onesta', "primo controllo registrato"); RLS member SELECT/UPDATE gia' attiva; indici ws_domain+ws_created presenti. #457 (engine Fase 1) in master; #468/#474/#478 tutti e 3 APERTI e impilati (#468→#474→#478) → la UI/engine multipagina vivono solo sullo stack → PR5 stacked su #478. Superficie Sole trovata (non inventata): api/ai/sole-crm-suggestions.ts = pattern vivo (endpoint sincrono, Bearer+membership fail-closed, fallback deterministico) → ne ho fatto il gemello web.

3 decisioni founder (AskUserQuestion ben grounded):

1. Schema = DERIVATO, no migration (consigliata): lista = domini distinti con ultimo audit; trend = righe ordinate per created_at. monitored_sites dedicata guadagnerebbe il posto solo INSIEME al cron (cadenza+flag) → YAGNI ora.
2. Cron settimanale = COSTRUITO ORA (founder ha sovrascritto il mio "differisci"). Senza tabella dedicata, pilota sul set derivato: domini con ≥1 audit done fermi da >7gg. Guardrail di costo espliciti (decisione di costo, modalita' risparmio): 1 cron settimanale (0 4 * * 1), cap 25/tick oldest-first, salta i pendenti (no doppioni QStash), gate CRON_SECRET, accoda e basta (il worker QStash fa il crawl quota-aware PSI/CrUX). Non muove i numeri del guardrail spesa (≤25 audit/sett).
3. Tutto in una PR coerente (consigliata).

Costruito (PR #481, branch feat/web-hub-monitored-sites, stacked su #478): logica pura testata src/lib/web-hub/tracked-sites.ts (26 test: dedup ultimo-per-dominio + sparkline/delta, trend ultimo-vs-precedente, selezione cron cost-aware, policy "prossima mossa" del Sole) · GET /api/web-hub/sites (lista + ?domain= storico, service-role + filtro workspace_id esplicito) · GET /api/web-hub/sole-suggestions (deterministico, zero-token, gemello di sole-crm) · cron api/cron/web-hub-reaudit.ts + entry vercel.json · helper enqueueMultiPageAudit condiviso con /start (no duplicazione) · UI TrackedSitesList (sparkline SVG senza libreria + trend espandibile) + SoleNextMove, montati in MySitesPage con ri-controllo + invalidazione a fine audit.

Verifica (born-green LOCALE, install worktree completata): tsc src + tsc -p tsconfig.api.json + vitest run (1971 pass, +26, 0 regressioni) + eslint src/ api/ (0 errori, nessun warning nei file nuovi) + knip + depcruise (0 violazioni nuove, 946 moduli) + vite build (4m07s) tutti verdi. Commit b0312e4. ⚠️ La CI required Typecheck+build gira solo su PR→master → non parte sullo stacked: i gate locali sono il controllo. Giro prod reale (URL→trend→ri-controllo) = founder a Vercel ripristinato.

Stato: PR #481 born-green, merge = founder nell'ordine #468→#474→#478→#481. Cron live al merge+deploy (con CRON_SECRET gia' impostato, #371). Follow-up registrato (chip): valutare un AI-polish opzionale dei suggerimenti del Sole (voce del brand) oltre alla versione deterministica. Memory: project_external_site_hub_monitored_2026_06_30.

Owner: Gregorio (decisioni + merge) · Claude (verifica stato reale + design + build born-green)

Chi: Gregorio (due scelte via menu v199). Claude (allineamento BOS).

DECISIONE 1 — WhatsApp via Meta DIRETTO, 360dialog SCARTATO (supera la raccomandazione "Fase 1 = 360dialog" di v198/v199). Verbatim founder: "faremo tutto con Meta senza 360, così abbiamo una sola cosa su questo almeno, altrimenti troppe piattaforme a cui rendere conto." → una sola piattaforma (Meta) per FB+IG+WA. WhatsApp = WhatsApp Business Cloud API ufficiale, noi Tech Provider che ospita il proprio Embedded Signup contro Meta (i Tech Provider possono). Vantaggi: un solo rapporto/billing (Meta), niente fee BSP (€49 diretto / €500 partner spariscono), niente gateway proprietario waba-v2.360dialog.io, niente billing EUR/CHF intermedio, costo = solo messaggi Meta, margine massimo. Trade-off accettato: la nostra App Review WhatsApp senza corsia veloce BSP + gestiamo noi l'integrazione Cloud API. Il deep-dive 360dialog (v199) resta come alternativa valutata e scartata (ricerca di riferimento nella strategia, sezione 5). Coerente: IG/FB erano già diretti → ora anche WA, "one connection" più pulita.

DECISIONE 2 — Prep-code OAuth = ASPETTA la testabilità (opzione B di v199). Non si scrive il codice ora (non verificabile: Vercel giù + no Meta App + auth/token = security). Lo spec corretto (strategia sezione 9: route serverless Vercel meta-init+meta-callback con state HMAC + RPC pgcrypto + fix mismatch provider 'meta' vs meta_instagram/meta_facebook) rende il Giorno-0 "premi invio". Codice quando Vercel è su + Meta App esiste, con review avversariale sul path auth.

Stato: tutto gated sulla Sagl (verifica Meta Business unica per FB+IG+WA) + sblocco Vercel. Niente da costruire ora. Doc: execution/meta-integration-strategy-2026-06-30.md. Memory: project_meta_integration_strategy_2026_06_30.

Owner: Gregorio (decisioni) · Loris (Sagl) · Claude (codice post-testabilità)

---

Chi: Gregorio (ha scelto entrambe le opzioni del menu v198: "costruisci ora la prep codice" + "deep-dive 360dialog fee/contratto/scope"). Claude (subagent web 360dialog + lettura codice reale api/oauth/* + api/_lib/marketing/meta-*).

CORREZIONE COSTO 360dialog (regola costi-sempre-allineati): la mia v198 diceva "~€49/mese" per 360dialog — impreciso. Realtà (docs ufficiali): il Partner/ISV program ha una platform fee fissa €500/mese (Growth) + €25/numero; i €49/mese per numero sono il piano DIRETTO single-account (zero platform fee). → Fase 1 = piano diretto €49/numero (validi su pilota); Fase 2 = Partner Growth €500/mese solo quando >~15-20 clienti WhatsApp (la fee si diluisce). Markup messaggi = €0 (pass-through Meta) confermato. Billing EUR/USD, NON CHF. Scope = SOLO WhatsApp (IG/FB/Messenger NON coperti → Meta Graph API diretta). Anti-lock-in OK: WABA del cliente, numero portabile (lock-in solo nel codice: waba-v2.360dialog.io + API key/numero).

AUDIT CODICE OAuth (perché NON costruisco il codice adesso) — 3 scoperte che il piano interno stale non vede:

1. Piano docs/plans/2026-02-25-meta-integration.md = STALE: punta al progetto Supabase MORTO iouqemthcpccyyfhcrno (MAIND), path frontend/maind-dashboard/, cifratura XOR giocattolo, Edge Function Deno. Architettura SBAGLIATA.
2. Pattern reale = route serverless Vercel (api/oauth/google-callback.ts + x-callback.ts): state HMAC-firmato via -init (Bearer+membership) → exchangeCode → callRpc('set_google_oauth_connection', …pgcrypto) → 302. L'attuale buildMetaOAuthURL usa state non firmato (btoa) = gap di sicurezza da chiudere con un meta-init.
3. LANDMINE provider mismatch: insights legge meta_instagram/meta_facebook (meta-tokens.ts), frontend scrive/legge 'meta' (analytics.ts/SocialInsightsTab). Connessione e sync non si parlano → bug latente. Decisione Giorno-0 (Opzione A consigliata: un'unica conn 'meta', allineare meta-tokens/meta-sync).

RACCOMANDAZIONE (orient-then-ask, charter: auth/token = security → chiedo): il pezzo alto-valore (init+callback+RPC su path token LIVE + fix mismatch su insights LIVE) è multi-pezzo e security-sensitive e non verificabile ora (Vercel bloccato = no deploy/CI; no Meta App = no test round-trip; no permessi = no test publishing/messaging). Scriverlo alla cieca viola il Charter (verifica = massima leva; niente speculativo; auth → Generator-Verifier). → Ho prodotto lo spec tecnico CORRETTO (sezione 9 di meta-integration-strategy-2026-06-30.md) che rende il Giorno-0 "premi invio"; il codice si scrive quando è testabile. Founder decide: (A) scrivo comunque ora born-green-solo-locale su worktree, accettando che è non testabile; (B) aspetto la testabilità (consigliata).

Owner: Gregorio (decide A vs B) · Claude (spec corretto fatto · codice post-testabilità)

---

Chi: Gregorio (ha chiesto se OpenWA permette di integrare WhatsApp "per tutti gli utenti, per sempre, scalabile"; poi ha allargato a "connessione Meta in generale su FB+IG+WA, abbiamo fretta"; ha riconosciuto che la verifica si fa "per tutta Meta insieme quando abbiamo la Sagl"). Claude (ricerca web 2026-06-30 su OpenWA + percorso Tech Provider ufficiale + confronto BSP + audit del codice esistente con subagent).

DECISIONE 1 — OpenWA / WhatsApp non ufficiale = SCARTATO. @open-wa/wa-automate pilota WhatsApp Web via browser automation + QR → viola i ToS Meta (client reverse-engineered, uso automatizzato/bulk). Detection a livello di protocollo (fingerprint dei client non ufficiali), non di comportamento → le "anti-ban features" non bastano. Conseguenza = ban permanente del numero, senza ricorso. Per un SaaS multi-tenant è lo scenario peggiore: bruci il numero del cliente, con liability founder CHF 250k + danno reputazionale al moat "affidabilità". Licenza Hippocratic+DoNoHarm (non MIT) + funzioni a license key. → Mai sul numero di un cliente.

DECISIONE 2 — Il modello giusto = Meta Tech Provider, UNA connessione per tutto. FB+IG+WA non sono tre integrazioni: sono 1 Business Portfolio verificato → 1 Meta App → N prodotti, con App Review per-permission. Multiverbe è un "Tech Provider" (software che fa usare Meta ai clienti). Onboarding clienti scalabile = Embedded Signup (WhatsApp) + Facebook Login for Business (IG/FB): pochi click, asset di proprietà del cliente e revocabili (coerente nDSG + Hub Messaggi CRM).

DECISIONE 3 — Avvio gated sulla Sagl, verifica UNICA per tutta Meta (founder 2026-06-30). Il collo di bottiglia non è il codice (vedi sotto) ma la Business Verification, che richiede l'entità legale (estratto registro di commercio, IDE). Già previsto nel pinned_focus di Loris. Quindi: si attende la Sagl e si fa la verifica una volta, per FB+IG+WA+Ads insieme. Nel frattempo si può costruire/testare su Standard Access con account nostri (non serve verifica per sviluppare e fare le chiamate-prerequisito dell'Advanced Access).

DECISIONE 4 — BSP per partire veloce = 360dialog (Fase 1). Tariffe messaggi identiche (sono di Meta). 360dialog: 🇪🇺 EU, billing EUR, ~€49/mese, zero markup (pass-through), partner platform multi-tenant + Embedded Signup → corsia veloce WhatsApp (scavalca parte dell'App Review WA). Fase 2 = valutare accesso diretto Meta a volumi maturi. Twilio/Bird sconsigliati early-stage (markup per-messaggio). Costo messaggi CH (listino EUR Western Europe): utility ~€0.03–0.05 (caso principale = conferme booking), marketing ~€0.10–0.13, service gratis (1.000/mese gratis per WABA) → pochi franchi/cliente, monetizzabile nei tier Pro/Business.

AS-BUILT (audit codice 2026-06-30, subagent) — molto è GIÀ pronto, day-0 parte da qui:

• ✅ DB oauth_connections (provider meta_facebook/meta_instagram, token cifrati, RLS) + crm_messages.channel ∈ {email,whatsapp,sms,ig_dm}.
• ✅ Instagram Insights sync 90% (api/marketing/meta-sync.ts + meta-insights.ts + meta-tokens.ts) — gated da META_INSIGHTS_ENABLED=1, API pin v25.0.
• ⏳ OAuth flow 70% (client OK + form token manuale già funzionante; manca Edge Function meta-oauth-callback, ~100 righe, template nel piano docs/plans/2026-02-25-meta-integration.md).
• ⏳ FB Pages 30% (schema+scopes, manca adapter). ⏳ WhatsApp messaging 10% + ⏳ IG DM 10% (DB+UI pronti, api/messages/send.ts = 501, no adapter Graph).
• Env: META_APP_ID/META_APP_SECRET/VITE_META_APP_ID/OAUTH_TOKEN_ENCRYPTION_KEY.

App Review a fasi: prima publishing IG/FB + WhatsApp (alto valore, più facile), poi ads_read (Marketing, "Advanced Access trap"). Aspettativa: WA via BSP giorni–1 sett; IG/FB publishing 2–4 sett; tutto 3–6 sett se verifica parte Giorno-0.

BLOCCHI: (1) Sagl non costituita = gate #1 (Loris); (2) Vercel bloccato per pagamento = anche a Meta pronta il deploy prod è fermo (Gregorio, urgente).

Doc completo + checklist Giorno-0: execution/meta-integration-strategy-2026-06-30.md. Reminder: action_item in status.json + execution/meta-reminders-2026.ics (check settimanale Sagl→verifica). Memoria Claude: project_meta_integration_strategy_2026_06_30.

Owner: Gregorio (decisioni) · Loris (Sagl → sblocca verifica) · Claude (ricerca + esecuzione codice post-Sagl)

---

Chi: Gregorio (ultimo item dell'epica · "costruisci il runtime; correggi Gemini dopo verifica; aggiorna tutto"). Claude (3 layer born-green + ricerca web stack 2026 + correzione sovranità Gemini).

Cosa: costruito tutto il compute del loop che porta i siti generati a qualità "ship" — il checker deterministico (Lighthouse/CWV/axe/layout · #466) trova i bug, una giuria vision giudica il "gusto"/premium, e decideVisualLoopOutcome decide ship/fix/accept_with_warning con direttive azionabili. 3 layer: (1) logica pura visual-jury.ts; (2) dispatch giuria vision sovrano EU (dispatchVision + adapter Vertex EU multi-region + runVisualJury); (3) percezione (PSI v5 client + contratto render Cloudflare + mapper axe/assembly). Mirror del pattern model-as-judge (#463/#476): core puro testato, runner impuro a parte.

Decisioni founder (2026-06-30, via menu):

• Render = PSI v5 (Lighthouse/CWV · i siti hanno URL pubblici → niente browser headless, off-Vercel-compute, cost guardrail) + Cloudflare Browser Rendering EU (screenshot 3 viewport + axe).
• Giuria = Gemini 3.5 Flash EU + Opus 4.8 EU (entrambi Vertex EU multi-region, vision).
• Runtime = Inngest durabile (NON Vercel-fn).

⚠️ Correzione di sovranità (founder "il più nuovo è 3.1, verifica" → la verifica web rivela di più): Gemini 3.1 Pro è GLOBAL-only su Vertex (NON multi-region EU) → userebbe un endpoint fuori-EU e romperebbe la residenza (gli screenshot mostrano nome/indirizzo/persone e NON sono pseudonimizzabili → residenza EU = base giuridica). L'unico Gemini 3.x GA + raggiungibile EU è gemini-3.5-flash (che per giunta batte 3.1 Pro sui benchmark). 3.5 Pro: GA EU attesa luglio 2026 → upgrade con 1 sola env, zero deploy. Quindi seggio Google = Gemini 3.5 Flash EU, id giurati resi version-stabili.

Stato: PR #480 (3 commit) born-green VERIFICATO IN LOCALE + CI VERDE (Typecheck+build, Semgrep, Frontend, Trivy, gitleaks; Vercel rosso = outage 402, non-required). Migration-free. Coda merge post-Vercel: #479→#477→#480. canon/05-stack.md aggiornato (voce "QA visiva siti"). RESTA solo il runtime LIVE (worker Inngest + impl Cloudflare render + persistenza design_reviews + fix→re-render) = founder-provisioning (PSI_API_KEY + credenziali Cloudflare Browser EU) → chip task_53b443cb. Con quello l'epica "stack LLM SOTA 2026" è CHIUSA. Memory: project_llm_stack_2026_epic_2026_06_25.

---

Chi: Gregorio (richiesta: "le 5 task più importanti" → poi "mappa cosa è merged-ma-non-vivo, dammi la lista azioni, salva in BOS"). Claude (3 fronti verificati: migration prod vs repo via MCP · advisor security+perf live · censimento righe reali · 2 subagent paralleli su env-gating + core-non-cablato).

Cosa (verdetto): il lavoro recente è in prod come schema ma a 0 utilizzo — manca un interruttore acceso, non altro codice. Censimento righe prod: Booking 28 / CRM-LTV 22 / agent_runs-7gg 104 / compliance 18 = VIVI; content_items 1 + calendar 0 / external_site_audits 0 / oauth_connections 0 / planet_goals 0 / site_legal_reviews 0 = merged-ma-mai-esercitato. Il Sole pensa (brain US-direct) ma il Content non genera (gateway sovrano Vertex EU spento → 503).

3 fronti:

• A · DB: PULITO. Nessun drift (migration PR aperte già applicate via MCP). Falso allarme "native_api NULL" #462 = colonna reale connection_type. Advisor 0 ERROR (barra re-baseline PASS); 3 WARN minori (recovery_codes_status SECURITY DEFINER + 2 multiple_permissive su lead_candidates/sales_icp_profiles) + igiene INFO (62 FK senza indice, 113 unused — contano a scala).
• B · Dormant env-gated (founder, appena Vercel su): per leva → Vertex AI EU (4 env, accende TUTTO il Content) · Inngest (2 env, il Sole-che-AGISCE + auto-publish) · Onboarding V2 (VITE_ONBOARDING_V2=true, gratis) · Connettori Google+Clarity (OAUTH_TOKEN_ENCRYPTION_KEY) · QStash · Push VAPID.
• C · Core non cablato (serve codice): orchestratore specialisti (6 specialisti + 7 helper, 0 ref non-test, mai chiamato — sblocca anche target_planets, effort M) · visual-QA loop (@wip, L) · scoreAndRank dead code (cancellare, S). ✅ model-as-judge confermato cablato da #476.

Correzione onesta: l'auto-publish social mainstream (Meta/LinkedIn) NON è un bug, non è costruito per ToS (content-scheduler.ts). Content non consegna per 2 interruttori spenti (Vertex+Inngest) + #415 da mergiare.

Doc completo + checklist azionabile: ops/finto-fatto-audit-2026-06-30.md. Stato: nessuna modifica codice/DB in questa sessione (Vercel giù, founder ha scelto "salva e chiudi"). Memory: project_finto_fatto_audit_2026_06_30.

---

Chi: Gregorio (continuazione ITEM 4 · "efficienza cache_read"). Claude (cablaggio + born-green locale).

Cosa: misura il risparmio del prompt caching. I token serviti dalla cache (cache_read_input_tokens) erano conteggiati DENTRO input_tokens (totale) ma non isolati → risparmio non quantificabile. Ora agent-core espone cached_input_tokens (opzionale · input_tokens resta il totale → quota AI invariata) e recordAgentRun lo persiste in agent_runs.cache_read con un UPDATE separato best-effort dall'insert base → finché la migration 2026-06-29d (additiva, gated) non è applicata la telemetria base NON regredisce. Writer admin untyped → nessuna dipendenza di build sulla colonna nuova.

Batch API −50%: NON in questa PR · già deciso come refactor a sé in v191 (COSTO AI: insight loop→one-shot + cron collect→batch→poll, da non rushare).

→ ITEM 4 COMPLETO: PR5 cron run_hour (v193, #477) + cache_read (#479). Dell'epica resta solo ITEM 2 (visual-loop Inngest, provisioning founder).

Verifica: born-green locale (typecheck:api + 1939 test + lint 0-err + knip + depcruise). Owner: Gregorio (merge a CI verde · applica migration via MCP). Stato: PR #479 aperta. Memory: project_llm_stack_2026_epic_2026_06_25.

---

Chi: Gregorio (4 decisioni via AskUserQuestion: architettura · scoperta pagine · velocità · forma del report). Claude (ri-validazione web Vercel/QStash + cablaggio + born-green locale).

Cosa: il motore audit siti esterni (#457 motore · #468 UI · #474 performance) passa dalla sola home a N pagine reali del sito. Architettura async, 1 worker QStash (pattern site-builder start->worker->status), scelta dal founder fra 3 opzioni; migliora lo schizzo iniziale (fan-out per-pagina) perché scrittore unico = niente race, 1 messaggio/audit (500/giorno free vs ~83), niente RPC/migration. POST /api/web-hub/audit/start accoda (riga external_site_audits queued + publishJSON, fallback inline senza QStash) → worker firma-verificata audita tutte le pagine entro deadline e persiste → status polling con progresso X di N.

Decisioni founder (verbatim "tutto quanto senza eccezioni / max / report breve serve più a Multiverbe"):

• Scoperta: sitemap.xml + link interni same-origin, prioritizzati per navigazione (servizi/contatti/prezzi/prenota/prodotti, multilingua IT/DE/FR/EN). Tetto 14 pagine + deadline wall-clock (crawl 55s / totale 100s) = il "max" responsabile (massima copertura senza 504 / timeout QStash).
• Velocità: PSI+CrUX su tutte le pagine, concorrenza 3 verso Google + deadline (rispetta le quote, degrada fail-soft).
• Report: breve per l'utente (verdetto sito home-pesato 60/40 + interventi deduplicati per id con pagine in evidenza), ricco per il Sole (per-pagina completo persistito in signals.pageReports).

Sicurezza: ogni fetch (home, ogni pagina, sitemap) dal safe-fetch SSRF-hardened; worker verifica sempre la firma QStash + ownership al data layer; start/status Bearer+membership. Nessuna migration (schema LIVE già regge: status CHECK queued/running/done/error, signals jsonb, pages_crawled).

Verifica: born-green LOCALE (install worktree exit 0): tsc src+api · vitest 1940 pass (+20 test puri: discover/aggregate/extractInternalLinks/parseSitemapUrls) · eslint 0 errori · knip 0 · vite build · depcruise 0 nuove. ⚠️ Required Typecheck+build gira SOLO su PR->master: PR stacked su #474 → non parte, i gate locali sono il controllo.

Owner: Gregorio. Stato: PR #478 aperta, mergiare nell'ordine #468 → #474 → #478. Giro prod reale (URL multipagina → report) a Vercel ripristinato (outage 402 fino ~3 lug). Chiude il chip multipagina. Memory: project_external_site_hub_pr4_2026_06_29.

---

Chi: Gregorio (continuazione ITEM 4). Claude (cablaggio + born-green locale).

Cosa: i 3 cron notturni del Sole (analyze-planet-data 06:00 · memory-sync 07:00 · memory-consolidation 03:30 Europe/Zurich) passano da ora FISSA a tick orario (0 * * * *) + gate per-workspace su workspaces.memory_settings.run_hour (ora preferita 0-23). Chiave del JSONB già esistente → nessuna migration; non impostata → ora storica del cron → zero regressione. Helper puro api/_lib/run-hour.ts (DST-safe via Intl) + UI NightlyHourSection nel tab AI (Business · "Automatico" = default). memory-sync mantiene il backfill embeddings a cadenza giornaliera (niente ×24). Nessun cambio canon (è scheduling, non model/cost-stack).

Costo: +24× tick/giorno ma solo query leggera + filtro; lavoro pesante invariato. Inngest dormiente in prod → inerte fino all'attivazione founder.

Verifica: born-green locale (typecheck:api + 1939 test, +10 run-hour, + lint/knip/depcruise). ⚠️ tsc&&vite build src non verificabile su questa macchina (bug noto @types/react/JSX Windows · 543 errori sistemici repo-wide, master CI-verde) → CI è il gate per il build src; file toccati = 0 errori non-sistemici.

Owner: Gregorio (merge a CI verde). Stato: PR #477 aperta. RESTA ITEM 4 parte 2 (efficienza: cache_read in agent_runs + Batch API −50%, migration founder-gated). Memory: project_llm_stack_2026_epic_2026_06_25.

---

Chi: Gregorio (decisione di conformità: dove deve girare il giudice quando vede PII di prospect). Claude (cablaggio + verifica web id GA Sonnet 4.6 su Vertex + born-green locale).

Cosa: il model-as-judge CORE (#463, finora puro e non chiamato) ora è acceso sui 3 punti d'azione difficili da ritirare. Un modello forte rilegge l'output del modello economico PRIMA dell'azione:

• sales/send-outreach (cold email reale) → fail-OPEN (giudice-giù NON blocca il flusso live · default documentato); un REJECT esplicito blocca (422).
• connectors/x/post (post pubblico · oggi dormiente) → fail-CLOSED (raggio ampio, difficile da ritirare → giudice-giù NON pubblica · 503); REJECT → 422.
• messages/draft-reply (bozza CRM human-gated) → advisory: campo review additivo che annota, non blocca.

Decisione di conformità (founder): il giudice gira sul gateway sovrano EU (purpose 'judge' → Claude Sonnet 4.6 su Vertex AI EU), NON Opus US + pseudonimizzazione. Motivo: per cogliere le fughe di PII il giudice deve vedere il testo reale (nomi inclusi); la residenza EU è la base giuridica (nDSG/GDPR) che lo rende lecito senza far uscire il dato dal confine. Coerente con la v191 "COSTO AI" sotto (tutto Anthropic in EU via Vertex). Il gate PII centralizzato gira comunque (PII strutturata → token, che RENDE PIÙ VISIBILE la presenza di PII in un testo pubblico; i nomi restano sulla rotta sovrana). Rotta giudice = tier-invariante (Sonnet 4.6 EU per OGNI piano · la qualità del giudice è il moat, best-for-all) con Gemini 3.5 EU come fallback sovrano (il gate resta vivo e dentro confine su un outage transitorio di Claude). Nessun nuovo pin modello: riuso claude-sonnet-4-6 (verificato sul web: GA su Vertex, formato dateless = snapshot pinnato, EU via endpoint regionali europe-west).

Verifica: core puro invariato + nuova giuntura api/_lib/run-judge.ts + nuovo TextPurpose 'judge'. Born-green locale: typecheck:api + 1929 test (+10: 8 run-judge dispatch-mockato + 2 rotta judge) + lint 0-err + knip + depcruise tutti verdi. CI: security pass; Vercel rosso = solo outage account-blocked (402, non-required).

Owner: Gregorio (merge a CI verde · redeploy a Vercel ripristinato ~3 lug). Stato: PR #476 aperta. Memory: project_llm_stack_2026_epic_2026_06_25.

---

Chi: Gregorio (visto un video "non usare Supabase/Vercel per prodotti API-based"; deciso poi: ottimizzare il costo AI via caching + "utilizziamo come da regola tutto in europa" + "il Sole non deve perdere nulla, era settato per funzionare al meglio"). Claude (audit con 2 subagent paralleli sui ~16 call-site AI + ricerca web prompt caching 2026 + 3 PR verificate in locale).

ARCHITETTURA AI REALE (scoperta dall'audit): due piani distinti per sensibilità del dato.

1. Gateway sovrano (api/_lib/sovereign/) per contenuti coi dati dei clienti → Gemini Vertex EU (content), Mistral FR (outreach/messaggi), Claude-su-Vertex-EU (vertex-claude-eu, longform/client-copy Business). Default-sovrano, fail-closed, backend proibiti hard-bloccati (DeepSeek/OpenRouter/Google-consumer). Zero caching oggi.
2. Anthropic-US-diretto (llm-client.ts + agent-core.ts) per il cervello del Sole (chat sole-ask, loop agentici insight/CRM/strategist, site-builder) su aggregati/pseudonimizzati. Qui il cache_control esiste ma spesso inerte (prefisso <1024 token) o cache-defeated (sole-ask infilava dati per-domanda nel prefisso). NB: Claude è già usato in EU via Vertex — l'intuizione founder era giusta.

DECISIONE founder (bloccata): unificare tutto Anthropic in EU via Vertex, dismettere US-direct. Trade-off accettato: si perde caching automatico (non usato) + Batch API nativa Anthropic (→ Vertex batch prediction); si guadagna sovranità totale (nDSG, liability CHF 250k) + un solo adapter. Content/Sales restano dove sono (già EU).

3 PR — TUTTI i gate codice GitHub VERDI (typecheck+build, lint, Semgrep, Trivy, TruffleHog, gitleaks, audit, 1400+ test; verifica in locale via worktree mv-eu-cache + symlink node_modules dal main → tsc/vitest girano senza install, in cost-mode):

• #472 (Stadio 1): cache_control esplicito su Claude-Vertex EU + telemetria cachedInputTokens/cacheWriteTokens su vertex-adapter.ts. Base master.
• #473 (Stadio 2, DORMIENTE): cervello → Vertex-EU dietro flag BRAIN_EU_VERTEX (OFF default, fail-safe: se acceso ma Vertex non configurato resta US). vertexClaudeRawMessage() (formato Anthropic completo system+tools+messages su rawPredict) + brain-routing.ts. Branch su Vertex con auth GCP (no key US).
• #475 (Stadio 2b): sole-ask prompt a 2 segmenti (prefisso stabile cachato + dati variabili nello userPrompt). Indipendente. Base master.

QUALITÀ PRESERVATA (direttiva founder) — 2 regressioni intercettate e chiuse su #473: (1) mapModelToVertex preserva la famiglia (Opus resta Opus, NO downgrade silenzioso a Sonnet che avrebbe degradato lo strategist); (2) temperature su Vertex solo se passata → default identico al percorso US (agent-core non la imposta). 2b: il modello riceve gli STESSI contenuti, solo riposizionati (sole-ask 13/13).

⚠️ GATE FOUNDER reali:

• Vercel ACCOUNT BLOCCATO ("Account is blocked" su tutti i deploy CI delle 3 PR — billing/cost-mode). I gate GitHub sono verdi: è SOLO Vercel a bloccare il merge-to-prod. Azione: sbloccare billing Vercel.
• Per accendere lo Stadio 2: quota Claude su Vertex EU (europe-west1/4) + pin id Opus/Haiku via env se servono + smoke test live (BRAIN_EU_VERTEX=1, chat + 1 loop, telemetria cachedInputTokens>0 al 2° giro).

STADIO 3 (NON fatto · NON è un drop-in): il Batch API (−50%) richiederebbe convertire l'insight agent (analyze-planet-data) da loop tool-use a one-shot (cambia il comportamento del Sole) + ristrutturare il cron Inngest da fan-out per-workspace a collect→batch-submit→poll→persist. È un refactor a sé, da NON rushare. È il win misurabile più sicuro (lì la cache già scatta, prefisso ≥1024).

NOTA ONESTA SUL RISPARMIO: il caching rende solo sopra 1024 token di prefisso stabile; sole-ask (~500 tok) può non superarli → 2b rende la struttura corretta ma il guadagno misurabile lo dà la telemetria dello Stadio 1. Memory: project_ai_caching_audit_2026_06_29, project_infra_exit_plan_2026_06_29.

Owner: Gregorio. Stato: 3 PR aperte, gate codice verdi, merge bloccato da Vercel (founder). Stadio 3 = task dedicato prossima sessione.

Chi: Gregorio (mandato: aggiungere la velocità reale al report audit, da due fonti Google separate). Claude (ricerca web 2026 su PSI v5 + CrUX API, soglie Core Web Vitals; build born-green).

Cosa: il motore di audit siti esterni (#457) ora misura anche la velocità reale del sito e la inietta nel report white-label (#468). Due fonti Google separate e complementari, side-by-side field-first:

• LAB · PageSpeed Insights v5 (Lighthouse): test sintetico, sempre possibile su un sito raggiungibile → punteggio 0-100 + LCP/FCP/TBT/Speed Index/CLS. La diagnosi tecnica (dove intervenire).
• FIELD · Chrome UX Report (CrUX): p75 degli utenti veri ultimi 28 giorni → i 3 Core Web Vitals (LCP/INP/CLS) con verdetto + punteggio 0-100. Prova l'URL esatto, ripiega sull'origin. La verità su come va davvero.

Perché field-first: Google sta deprecando i dati CrUX dentro PSI → li chiediamo a fonti separate e nel report il campo (utenti veri) viene prima del laboratorio.

Difensivo (charter): le due fetch passano dal safe-fetch SSRF-hardened condiviso (host fissi Google, comunque https + timeout + cap byte). Gated sulle key già su Vercel (GOOGLE_PAGESPEED_API_KEY / GOOGLE_CRUX_API_KEY, v183): senza key / su errore / timeout → performance.available=false e l'audit torna comunque (mai blocca). Risposte Google = dati esterni non fidati → parsing difensivo su unknown. Persistenza nel signals jsonb esistente → nessuna migration. UI degrada con onestà ("dato non disponibile").

Quote: PSI 25k/giorno · CrUX 150/min (margine ampio: l'endpoint è rate-limited 12/IP, 2 fetch per audit).

+ Findings azionabili (richiesta founder "punto 1 perf, estrema qualità big-tech"): la velocità lenta non resta nei gauge → ogni Core Web Vital non "good" diventa un intervento nella lista "cosa fare prima" + nel 2x2 impatto×sforzo. Il campo è la verità (1 finding per CWV non-good, niente doppione dal lab); senza dati di campo ripiega sul punteggio Lighthouse. Nuova categoria performance ("Velocità"), CLS = quick-win (effort basso), copy IT concreta con evidenza p75.

Verifica: parsing PSI/CrUX, mappatura a 0-100 e generazione findings puri e testati (39 test nuovi · soglie CWV ufficiali validate sul web 2026). Born-green locale: tsc src+api, vite build, vitest (1920 pass), eslint (0 warning), knip (0 issue). ⚠️ Il giro prod reale (URL → punteggi + findings nel report) lo fa il founder quando Vercel torna su (outage 402 fino al ~3 lug); pre-key/pre-deploy il comportamento è sicuro. ❌ Check Vercel rossi solo per l'outage account-blocked, non per il codice.

Multipagina (anche richiesto dal founder): crawl multi-pagina → PR4 separata, chip task_f84c521b (sessione/worktree fresco). Architettura decisa via spike SOTA 2026: async QStash, NON sync (PSI ~10-20s/pagina → N pagine in sincrono = invocazione lunghissima; Vercel Pro+fluid max 800s std/1800s beta ma idle-wait costoso + rischio 504; QStash ha 60s/messaggio = 1 pagina ci sta comoda). Riusa l'infra esistente (zero nuova dipendenza): api/_lib/qstash-client.ts + pattern identico a site-builder/start.ts→worker.ts (enqueue→worker firma-verificata). Quote da rispettare: PSI 25k/giorno, CrUX 150/min, QStash 500 msg/giorno → cap N (~6-8) + performance solo su home+pagine chiave. Aggregazione home-pesata + dedup findings cross-pagina.

Owner: Gregorio (merge dopo #468, redeploy a Vercel ripristinato). Stato: PR #474 aperta (2 commit), stacked su #468. Memory: project_external_site_hub_pr3_2026_06_29.

---

Chi: Gregorio (ha visto un video: "non usare Supabase/Vercel per prodotti API-based, scalando costano caro" → richiesta ricerca approfondita + come muoverci al meglio). Claude (ricerca web 2026 su pricing/alternative Vercel+Supabase + angolo sovranità del dato).

Contesto reale: l'infra dell'app — AI/Anthropic ESCLUSA, trattata come "sviluppo" a parte — costa oggi ~$50/mese (Vercel ~$26/ciclo + Supabase $25). Il video ha ragione a scala, ma sbaglia bersaglio ora: a $50/mese il rischio-rottura di una migrazione supera il risparmio.

DECISIONE (a TRIGGER, non ora): destinazione architetturale decisa adesso, esecuzione rimandata al primo dei due trigger:

• Supabase supera ~$150-200/mese, OPPURE
• arriva un cliente CH/enterprise che pretende dato sovrano EU/CH scritto nel DPA.

Al trigger, due decisioni disaccoppiate (problemi diversi, escape hatch diversi):

1. Data layer → Supabase self-hosted su Exoscale (🇨🇭 Zurigo/Ginevra) o Hetzner (🇩🇪). È lo stesso stack (pgvector, RLS, auth, storage) → il codice non cambia, migrazione a rischio quasi-zero. Costo piatto €25-100. Guadagno doppio: costo e riga "dato sovrano CH/EU" vendibile nel DPA.
2. Compute/API → Cloudflare Workers per le route API ad alto traffico (flat $5 + $0.30/M richieste, egress $0). La pena Vercel per un prodotto API-based: 5 metriche fatturate insieme + banda $0.15/GB oltre 1TB (≈$150/TB) + build CPU minutes (già $44/ciclo).

Il punto che il video NON dice (e per noi pesa di più del costo): Supabase, Vercel e Neon sono società USA → il CLOUD Act può obbligarle a consegnare il dato anche se ospitato a Francoforte. Residenza ≠ sovranità. Per un prodotto che vende conformità nDSG/GDPR come moat (+ liability penale founder CHF 250k), la migrazione del data layer è una decisione di sovranità prima che di prezzo. Exoscale/Infomaniak = sovrani CH (premio 20-30%, ma è una feature vendibile).

Vincolo operativo da SUBITO (per non trovarsi in lock-in al trigger): evitare feature Vercel-proprietarie non sostituibili.

ESCLUSO da questa decisione: i costi AI/Anthropic (= "sviluppo", ottimizzazione separata e immediata via prompt caching + Batch API, in lavorazione in questa stessa sessione).

Owner: Gregorio. Stato: deciso (destinazione), esecuzione a trigger. Ricerca completa consegnata in chat. Memory: project_infra_exit_plan_2026_06_29.

---

Chi: Gregorio (priorità epica "non sbagliare": ogni sito generato = il MIGLIORE della SUA categoria, al SUO posizionamento, nella SUA zona — una trattoria di quartiere = la migliore trattoria di quartiere, NON un lusso fuori posto; menu AskUserQuestion: valida il pattern in chat → greenlight "tutti i settori in fila + tutto il resto" → chip + chiudi + merge). Claude: framework + pattern + replica + verifica.

Contesto: lo Stage 1 Brand Strategist del site builder appiattiva i mood del settore in una lista di nomi e ignorava il posizionamento reale dell'onboarding → rischio "premium universale" (gold da fine-dining su una trattoria €). VINCOLI founder: NO "premium" universale · MAI il design-system Multiverbe ("Osservatorio") sui siti clienti (è la NOSTRA identità) · reference-grounding = leader REALI di quella categoria in zone simili, non "siti premium" generici.

Costruito (#467, 16 file +1046/-12, born-green):

• Framework puro src/lib/site-design/contextual-mastery.ts (typechecked + testato): deriveContextualPositioning restringe i mood candidati alla fascia reale via priceRange (fail-open se non calibrato → mai 0 candidati) + buildContextualMasteryDirective (principio + zona city/region + i leader REALI per-mood, NON i riferimenti fine-dining sector-wide che spingerebbero al lusso).
• types.ts: PriceRange + PositioningTier (banda RELATIVA al settore) + MoodSpec.positioning (priceRangeMatch + localLeaderArchetype). Innesto in stage-1-brand-strategist.ts (direttiva + 5° principio + enum JSON ristretto ai candidati) + thread city/region + tenant_choices (orchestrator + resolveTenantChoiceLabels).
• Tutti gli 8 settori calibrati: positioning su OGNI mood di restaurant + hair-salon + gym + professional-services + hotel + real-estate + studio-medico + aesthetics (7 agenti Sonnet paralleli proponevano dal targetClientProfile, encoding centralizzato per coerenza).

Decisioni di design: (1) deterministico su priceRange (segnale primario) + qualitativo su tenant_choices/intake; (2) deontologia per-settore: studio-medico MAI tier flagship (FMH/SSO/segreto art.321 CP → soffitto upper-tier, niente lusso/esclusività/superlativi/testimonianze), aesthetics nessun claim medico; (3) il top di categoria (flagship) è legittimo dove esiste davvero (resort di lago, immobili di pregio), ma l'everyday resta "il migliore della SUA categoria" su fiducia/radicamento.

Verifica / CI: born-green VERIFICATO IN LOCALE (install worktree ha funzionato): tsc + typecheck:api + 1878 test (+44 nuovi, incl. regression guard: positioning su ogni mood/settore + copertura €..€€€€ + assert studio-medico≠flagship) + lint 0-err + knip + depcruise tutti verdi. Validato sul web (best practice design ristoranti 2026 = "match design to type / avoid generic luxury"). CI code-gates verdi → #467 squash-MERGED; unici rossi = Vercel "Account is blocked" (outage 402, non-required, deploy live al pagamento ven 3 lug). Ortogonale a #454/#463 (nessun id-modello toccato).

Stato / azioni founder: ✅ MERGED. RESTA l'epica (chip task_126500ef, fresh session): item 3 judge-wiring live (Gateway sovrano EU Sonnet-4.6 deciso, vede testo reale per le fughe PII; core #463 in master) · item 2 visual-loop Inngest (checker #466 in master, serve provisioning Inngest+chromium) · item 4 PR5 cron run_hour + efficienza cache/Batch (migration founder-gated).

Owner: Gregorio (decisioni + greenlight) · Claude (framework + build + replica + merge). Memory: project_llm_stack_2026_epic_2026_06_25.

---

Chi: Gregorio (chip epic hub, autonomia piena). Claude: studio del codice reale (PlanetPanel/satelliti/useWorkspace) + ricerca web 2026 (gauge ARIA meter, 2x2 accessibile) → la UI che consuma il motore di #457.

Contesto: #457 (v181) ha mergiato il MOTORE di audit (POST /api/web-hub/audit → 2 voti Salute SEO + AI Search + fix impatto×sforzo; contratto puro src/lib/web-hub/audit/types.ts). Mancava la UI. PR2 = la cabina "I miei siti" del Pianeta Web: incolli un URL, ottieni il report vestito col TUO brand.

Costruito (PR #468, 8 componenti nuovi in src/components/web-hub/ + cablaggio):

• hook useExternalAudit (React Query mutation, Bearer della sessione Supabase, errori HTTP mappati IT); front-end puro, mai import da api/ (fetch).
• ScoreGauge SVG (semantica ARIA meter, web-verificata 2026), ImpactEffortMatrix 2x2 accessibile, FindingCard espandibile (perché/come + evidenza), AuditReport white-label (logo+colore+nome del tenant da useWorkspace), MySitesPage cabina (URL→audit→report + stati loading/empty/error IT).
• helper PURI format.ts (label IT, fasce voto colori Osservatorio, ordinamento priorità, assegnazione 2x2) con unit test.
• satellite web.site → MySitesPage; rimosso SiteBuilderLauncher superato (CTA "crea sito" assorbita); knip ignore ristretto allo scaffold connected-sites dormiente (audit/** ora vivo, sorvegliato).

Decisioni di design: (1) montare nel satellite web.site → ZERO impatto sulla scena 3D (vs aggiungere un 11° satellite); (2) gauge SVG a mano + 2x2 CSS-grid → niente libreria, bundle leggero (cost-mode); (3) colori dei voti SEMANTICI (verde→rosso = salute), il brand del tenant solo sulla cornice = separazione white-label corretta.

🔴 PROBLEMA INFRA (workaround fatto, radice founder-gated): l'install pnpm locale nel repo principale su questa macchina è ROTTO — Windows Defender (real-time ON) + disco D: meccanico corrompono il linking di vari pacchetti (typescript lasciato cartella VUOTA, idem autoprefixer/altri). 2 install (16min completato-ma-incompleto + 1 hang a 13min) bruciati. Diagnosi: store e progetto stessa volume (ok), verify-store-integrity=false già attivo, ma Defender scansiona ogni file linkato → link falliti silenziosi. NON sono admin → non posso aggiungere le esclusioni Defender. Workaround: materializzato typescript via npm pack+tar (bypassa il linking pnpm) → tsc gira. NB: una sessione-worktree parallela (v187) riporta l'install funzionante → il guasto è per-tree/timing-Defender, non globale.

Verifica / CI: tsc 0 errori sui file nuovi/toccati (i 9 errori residui sono ambientali, in file altrui con dep vuote: react-dom/d3-geo/stripe); check-internal-leaks 0. Gli altri gate (vitest/lint/knip/depcruise/build) NON girabili in questo tree → CI è il gate autoritativo (install pulito), come #457/#460/#465 questa settimana. Required = "Typecheck+build". Rossi non-required noti (Vercel 402 outage; SUPABASE_ACCESS_TOKEN 401 su RLS-isolation/types-drift) non bloccano.

Stato / azioni founder: (1) merge #468 a CI required verde; (2) FIX INSTALL (causa-radice della lentezza di oggi): lanciare con admin lo script esclusioni Defender (D:\Desktop\per claude\fix-dev-install-speed.ps1) + idealmente SSD; (3) Vercel venerdì 3 lug → redeploy → giro live del report su URL reale (oggi impossibile: 402 + vite dev non gira). Preview visiva del report mostrata in chat (mockup fedele). Follow-up (fuori PR2, per restare coesi): storico audit per dominio (external_site_audits), PSI lab/CrUX field, crawl multi-pagina QStash, spiegazioni AI + auto-fix, report condivisibile + PDF mensile.

Owner: Gregorio (decisioni + merge) · Claude (studio + build + PR + diagnosi infra). Memory: project_external_site_hub_pr2_2026_06_29.

---

Chi: Gregorio (menu AskUserQuestion: A=merge PR3a ora · B=loop perfezione visiva su runtime Inngest (worker async + step chromium+Lighthouse, NON Vercel-fn) · C=prossimo "1+2" = PR4 + maestria design contestuale; poi: "aggiorna BOS su continuativa + tutto il migliorativo, chiudi sessione, non lasciare nulla — prompt di handoff PARTITO"). Claude: esecuzione born-green verificata in locale (l'install pnpm del worktree ORA funziona — l'hang del 25/6 si è risolto nel gap → typecheck/test/knip/depcruise/lint girano qui, non solo CI).

Fatto + verde (3 unità):

• PR3a #454 (branch quizzical-shaw-554a1a) — model-swap end-to-end: copy site-builder Kimi→Sonnet 4.6, QA-gate Opus 4.8 per TUTTI i tier (era solo Pro/Business), opus-4-7→4-8 ovunque (anche prosa doc), fix cost-bug (primaryModelUsed nel try/catch · il vecchio response===undefined?… era codice morto → costo sempre attribuito al primary), Moonshot/Kimi RIMOSSO end-to-end (llm-client + .env + DEPLOY/SECURITY + sub-processore legale + codename customer-facing PlanetPanel/SettingsPage). Test llm-routing.test.ts. CI tutta verde · mergeable=CLEAN · OPEN. ⚠️ azione founder al merge: ripubblicare la pagina sub-processori (Moonshot tolto → la disclosure cambia).
• PR4 #463 (branch pr4-cascade-judge) — model-as-judge CORE (puro, 22 test): model-routing.ts classe 'judge'→Opus 4.8 (env MODEL_JUDGE) + model-judge.ts (buildJudgePrompt outreach/social/crm · parseJudgeVerdict Zod · decideOutcome fail-safe: REJECT blocca sempre, giudice-giù → fail-open default / fail-closed opt). CI verde · mergeable.
• Visual-QA checker (branch llm-stack-pr3b, commit 9e8d92e, 21 test) — soglie deterministiche "i check fanno i bug": Lighthouse≥90/95, CWV LCP≤2.5/CLS≤0.1/INP≤200, axe 0 critical-serious, 0 overflow/img-rotte/testo-tagliato, mobile-first 390→768→1280. src/lib/site-design/visual-qa/thresholds.ts (typechecked, @wip in knip finché il loop lo consuma). = fondamenta del loop (decisione B), da bundlare nel PR3b visual-loop.

RESTA — non lasciare nulla indietro:

• 🔄 Continuative (in corso · sessione fresca col prompt di handoff PARTITO): (1) Maestria design contestuale (founder "2", ⚠️ "NON sbagliare"): "MIGLIORE della categoria nella sua ZONA", NO premium universale, NO Osservatorio sui siti clienti → codifica nelle constitution (designPrinciples/mood-spec) + calibra su tenant_choices/priceRange, reference = leader REALI di categoria/zona (validare sul web); innesto stage-1-brand-strategist.ts. (2) Visual-loop Inngest (B): runner Inngest (render reale → evaluateVisualQa → giuria Gemini 3 Pro + Opus 4.8 su screenshot → fix → re-render fino a pass+ship) + bundla il checker; founder provisiona Inngest+chromium+chiavi. (3) PR4 wiring live (#463 è solo il core): innesto connectors/x/post.ts:54 (dormiente, rischio-0) · sales/send-outreach.ts (live, fail-open) · messages/draft-reply.ts (advisory) — scelta conformità: gateway sovrano EU Sonnet-4.6 RACCOMANDATO (vede il testo reale per le fughe PII, EU-resident) vs Opus US + pseudonimizzazione esplicita.
• ⚡ Migliorative: DRY cost-tracking (estimateModelCost orchestrator duplica estimateCostChf system-prompt → consolidare in un SSoT); valutare model-config.ts SSoT unico (oggi env-pin sparsi nei file naturali).
• 🗓️ Future: PR5 cron run_hour (UI Impostazioni pattern LocaleSection + tick orario 0 * * * * + gate workspaces.memory_settings.run_hour) · Efficienza (cache_read_tokens in agent_runs + Batch API Anthropic −50% sui cron notturni + semantic cache) — migration founder-gated · imagen-4-fast cleanup (advisory pool constitution · DEFERITO: intrecciato con PR2 #448 Nano Banana → farlo al merge di #448, allineando il roster advisory al reale) · POST-MERGE: allinea canon/05-stack + questo log + BOS (Kimi fuori, Sonnet copy, Opus judge).

Note: ogni PR da master corrente (master veloce: #450/#452/#439/#453/#458/#462 già dentro); PR3a/PR4 indipendenti dal resto + dallo schema. Vercel 402 fino a ven 3 lug (deploy bloccato; git/push ok). Memory project_llm_stack_2026_epic_2026_06_25 aggiornata con lo stato completo + handoff.

✅ MERGE (2026-06-29, founder "procedi"): #454 (PR3a · squash 0c15e01) + #463 (PR4 judge-core) + #466 (visual-QA checker · cherry-pick su master, CI verde) TUTTI MERGED in master. Sub-processori: la pagina /legal/subprocessors è code-driven (api/legal/subprocessors.ts) → riflette la rimozione di Moonshot al redeploy di venerdì 3 lug (Vercel 402 ora); nessun republish manuale + nessuna notifica clienti (il cron subprocessor-notify è per i NUOVI sub-processor con preavviso 30gg; Moonshot mai stato attivo = 0 dati condivisi). Branch merged non cancellati (cleanup opzionale).

Owner: Gregorio (decisioni + merge) · Claude (esecuzione born-green + verifica locale + merge autorizzato + handoff).

---

Chi: Gregorio (chip task_5403c096, mandato "sincronizza tutto": ogni prenotazione nel mio Google Calendar + i miei orari occupati bloccano gli slot). Claude: studio del codice OAuth/booking reale → estensione provider + sync 2-way fail-soft + funzione pura testata + UI → PR born-green.

Contesto: la parte Google era già pronta (infra v183): Calendar API abilitata nel GCP multiverbe-2606030125 + scope calendar.events+calendar.freebusy aggiunti al consenso → la verifica ora copre 4 scope (analytics.readonly + webmasters.readonly + calendar.events + calendar.freebusy = UNA review sola venerdì). Mancava solo il codice. Nessuna integrazione Calendar API preesistente: l'iCal channel hub (#453/#462) è cosa diversa (occupazione OTA, non l'agenda personale del titolare).

Costruito (PR #465, 14 file):

• Connessione: nuovo provider OAuth google-calendar in api/_lib/oauth-google.ts (scope MINIMI events+freebusy), separato dal consenso combinato GA4/GSC/GBP (chi collega l'agenda non si fa chiedere analytics; l'autorizzazione incrementale somma i grant). Pulsante "Connetti Google Calendar" in Impostazioni + card BookingCalendarSyncCard nel cruscotto Booking (collega/scollega in-place, owner/admin, commit d1cd584). Riusa storage oauth_connections + RPC pgcrypto + resolveGoogleAccess (auto-refresh).
• Write/update/delete: alla conferma prenotazione (widget anon + dashboard) crea best-effort l'evento nel calendario del titolare e salva l'eventId su bookings.google_calendar_event_id; alla disdetta lo cancella; alla modifica dal dashboard (update.ts: reschedule/dati/stato) aggiorna l'evento con events.patch (o lo cancella se status→cancelled) → agenda sempre allineata.
• Read/block: slots-available interroga freeBusy.query e rimuove gli slot orari sovrapposti agli orari occupati del titolare. Intersezione = funzione PURA subtractBusySlots (testata, confine half-open). Solo path orario (hotel a notte = stanze+OTA, non agenda personale).
• Fail-soft ovunque: nessuna chiamata Calendar blocca mai una prenotazione o il widget (stesso contratto di email/notifica), timeout su ogni fetch. Token cifrati mai loggati, nessun PII nei log, endpoint Google fissi (no SSRF), scope freebusy = solo occupato/libero.

Decisioni di design: (1) provider Calendar SEPARATO (non nel combinato) → scope minimi + modularità; (2) free/busy come funzione pura che filtra gli slot riusando il motore esistente, anziché sintetizzare blocchi finti; (3) evento con tz = fuso attività su istante UTC assoluto (DST-proof), cliente NON invitato (niente inviti a sorpresa), PII solo nel calendario del titolare (suo dato legittimo).

Migration 2026-06-29d APPLICATA in prod via MCP + verificata live (founder: "azioni founder tutte quelle che riesci"): bookings.google_calendar_event_id + indice parziale. Additiva/idempotente (ADD COLUMN IF NOT EXISTS) → 0 lock significativo, 0 advisor. oauth_connections.provider è text senza CHECK (verificato live) → nessun altro DDL. NON rigenerato src/types/supabase.ts (il regen tirerebbe dentro modifiche schema altrui già in prod ma non su master → non-coeso; schema-drift non-required + token-broken). Applicare il DDL senza deployare il codice è sicuro: la UI connect va live solo col redeploy → nessuno collega l'agenda prima → 0 eventi orfani. Resta solo MERGIARE il file su master (founder).

Test: provider→scope map (+ no scope-creep nel combinato), parse freeBusy difensivo, intersezione slot×busy, payload evento tz-aware. born-green: pure-node gate eseguiti (check:esm-api, check:leaks, check:business-parity tutti verdi); tsc/typecheck:api/lint/knip/depcruise/vitest/build = CI è il gate (install pnpm locale rotto su questa macchina, toolchain non materializzata). I rossi CI non-required noti (Vercel 402; RLS isolation + types↔prod su SUPABASE_ACCESS_TOKEN 401) non bloccano.

Stato / azioni founder venerdì 3 lug (migration GIÀ applicata → un passo in meno): (1) merge #465; (2) vercel redeploy; (3) pubblica app Google (Test→Prod) + submit verifica 4 scope; (4) giro reale: collega agenda → crea/disdici/SPOSTA una prenotazione → verifica evento Google (create/patch/delete); metti un impegno in agenda → verifica lo slot bloccato. Memory project_booking_google_calendar_sync_2026_06_29.

Owner: Gregorio (decisioni + merge) · Claude (studio + build born-green + PR).

---

Chi: Gregorio (decisione approccio via AskUserQuestion: "B + backfill TUTTI i workspace, demo inclusi"). Claude (orientamento su codice/DB reale → scelta A-vs-B motivata → migration canonica idempotente → apply MCP + verifica live + test trigger + consolidamento del duplicato di sessione).

Problema (verità DB prod): crm_contacts.total_orders / lifetime_value_chf (+first/last_order_at) erano seed finto gonfiato 6-15× vs realtà (ws demo LTV-colonna 12'565 vs vista 2'135), scritto da nessuna funzione DB. 7 reader LIVE li leggevano → numeri falsi/vuoti: Loyalty, planet-metrics (clienti-di-ritorno/churn), win-back+leads, sole-crm-suggestions, DirectoryPage, draft-reply, vista churn crm_contact_signals_v. first/last_order_at su 1/38 → win-back e churn morti.

Decisione A-vs-B → B (materializza vs ripunta-i-reader-alle-viste): B perché i 7 consumer leggono le colonne — incluso una vista SQL che gata su lifetime_value_chf>0 — e i reader han bisogno NELLA STESSA RIGA di colonne che customer_value_v non espone (marketing_consent_email gate GDPR win-back, acquired_at, loyalty_points); A avrebbe gonfiato la vista condivisa + richiesto di riscrivere la vista churn (più superficie, regressioni).

Come (2 migration, MCP, idempotenti): (a) 2026-06-29a_crm_contact_value_materialize — funzione RICALCOLO (non incremento) private.recompute_crm_contact_value + trigger AFTER su bookings/deals (UPDATE-of mirato) → colonne = cache con la stessa identica definizione di customer_value_v (status≠cancelled/no_show · COALESCE(total_chf,deposit_paid_chf,0) + deals closed_won · COALESCE(value_chf,0)); first/last_order_at = COALESCE(starts_at,created_at) (data visita, corretta per "non torna da >60gg", consistente con customer_value_monthly_v). SECURITY DEFINER + search_path='' in schema private, fail-soft, guardia no-op, backfill tutti i ws. (b) 2026-06-29b_deal_crm_contact_link — gemello del booking→CRM (#450) per Sales: trigger BEFORE INSERT collega ogni deal a un crm_contacts via contact_email → i deal vinti confluiscono nell'LTV.

Verifica LIVE (Supabase MCP, prod): 0 divergenze colonne vs vista su 38 contatti / 3 ws; trigger valore testato dal vivo INSERT(1/123.45) / UPDATE→cancelled(0/0/null) / DELETE(reset) + cleanup; deal-link 12/12 collegati, 2 vinti→LTV; advisor security 0 nuovi. SQL-only → 0 delta frontend, nessun regen tipi.

⚠️ Duplicazione (lezione operativa): sessione lunga compattata → un turno precedente aveva già fatto B + aperto #459 + applicato la migration alle 14:05; al resume l'ho rifatto da zero non vedendolo → #461 duplicata. Consolidato su #461 (versione canonica allineata a prod: date su starts_at invece di updated_at) + portato il deal-link invariato; #459 chiusa. A inizio sessione-resume: controllare PR aperte recenti + schema_migrations + memory follow-up PRIMA di ricostruire.

Owner: Gregorio. Stato: PR #461 aperta, migration già applicate+verificate in prod. Merge = founder (PR SQL-only → required Typecheck+build non scattano; admin-merge come #433/#450; le migration sono già in prod → basta mergiare il repo-file, no re-apply). Azioni founder infra (team-wide, non-mie): ruotare SUPABASE_ACCESS_TOKEN (PAT CI scaduto → 401 su RLS+types-drift di OGNI PR schema); Vercel account bloccato (fattura 9808, outage 402 fino a ven 3 lug). Memory: project_crm_ltv_materialize_2026_06_29.

Continuazione stessa sessione · churn scoring ACCESO (il 7° reader): la migration churn 2026-06-22c (crm_contact_signals_v + crm_contact_scores, RFM-T) era dormiente (non in prod) → applicata ora che lifetime_value_chf è reale. Score backfillati via SQL con la formula IDENTICA a churn-score.ts (bootstrap finché il cron Inngest riprende post-Vercel; l'upsert giornaliero rinfresca → no drift): 22/22 segnali → score reali (tutti 'medio', risk 42-52, reasons corrette). ⚠️ Bug sicurezza trovato+fixato: la vista era SECURITY DEFINER (la 2026-06-22c non aveva security_invoker) → leak cross-tenant via PostgREST → ricreata WITH (security_invoker=true) (advisor ERROR 0010 risolto). Fix nel repo-file (entra in #461). Lezione permanente: ogni vista che legge tabelle RLS DEVE essere security_invoker (default Postgres = DEFINER = bypassa la RLS).

---

Chi: Gregorio (chip task_cdf9d414, Fase 2 dell'epic channel hub; mandato plan-first + decisione canale via AskUserQuestion). Claude: ricerca eleggibilità web 2026 + verifica schema LIVE → decisione founder → build born-green + applica/verifica migration via MCP.

Ricerca eleggibilità 2026 (ri-verificata, è metà del valore) — le API native che porterebbero la reservation OTA + commissione pagata (obiettivo originale della Fase 2) sono confermate chiuse a noi:

• Booking.com Connectivity: onboarding nuovi partner SOSPESO ("pausing integrations with new connectivity providers until further notice; applications paused due to T&C update"). Anche se riaprisse: minimi da partner attivo (≥250 listing/gg daily-avg, ≥3.000 room-night/anno, 3 Foundational Solutions) fuori portata pre-revenue.
• Airbnb API: invite-only, nessun percorso di domanda (è Airbnb che invita su scala/maturità/supporto 24-7).
• Reserve with Google (Reservations E2E): ✅ unica porta native aperta — Partner interest form pubblico, "add your merchants' services to Google for free", eleggibilità = relazione contrattuale diretta coi merchant (Multiverbe ce l'ha coi tenant) + match Google Maps. Booking-SaaS partner senza fee/prenotazione esistono (Waitly, TIMIFY, ServiceTitan). NON è per hotel (= Google Hotel Ads a parte): copre ristoranti/beauty/fitness/servizi = esattamente il gap non-lodging che l'iCal della Fase 1 non serviva. Richiede booking-server ospitato (endpoint availability/create/update v3 REST + feeds SFTP + SLA <1s) + approvazione Google → build sostanzioso, verificabile solo post-approvazione.

Reframe: "misurare le commissioni OTA pagate" è bloccato (serve Booking.com/Airbnb, chiuse). RwG è un play diverso e più forte: non misura le commissioni, le azzera alla fonte (Google prenota diretto nel tenant, zero intermediario) → rafforza il moat "zero commissioni" e va oltre il lodging.

Decisione founder (AskUserQuestion 2026-06-29): "Fondamenta + form RwG" (vs "costruisci RwG E2E subito" / "pivota a Finanza dirette"). Predisponi schema/credenziali/RPC ORA (born-green, accessibile, niente build a vuoto), il booking-server RwG si costruisce quando Google approva.

Costruito (PR #462 · 1 migration additiva+reversibile · applicata+verificata prod via MCP):

• bookings.source → + booking_com|airbnb|vrbo|google (una reservation native = riga bookings reale; total_chf valore + crm_contact_id link CRM già presenti).
• bookings.external_ref + unique index (workspace_id,source,external_ref) = idempotenza ingestione (analogo di booking_slots.external_uid della Fase 1).
• booking_channels += connection_type (ical|native_api, default ical) + api_credentials_enc (pgp_sym cifrata) + provider_account_id + provider_meta; CHECK import_has_url→import_has_credentials (consapevole del connection_type: il vecchio avrebbe bloccato un import native).
• RPC service_role-only set/get_booking_native_channel (SECURITY DEFINER, search_path='', revoke PUBLIC+anon+authenticated — pattern identico agli iCal RPC #453). ⚠️ lezione: in Supabase i default privileges concedono EXECUTE a anon+authenticated ESPLICITAMENTE → revoke da PUBLIC non basta (l'advisor lo cattura).
• Verifica live: constraint/colonne/RPC/index + crypto round-trip + advisor security 0-new. booking_channels vuota → swap CHECK rischio zero.

Stato / azioni founder:

• Merge #462 = ✅ FATTO 2026-06-29 (squash admin, autorizzato founder "fai tu merge"; PR SQL-only → required "Typecheck+build" non scatta sui path database/**, pattern noto #433/#427). La migration è già live sul DB Supabase (applicata via MCP) → l'outage Vercel (v183, prod giù fino a ven 3 lug) non tocca questa PR (schema DB, non deploy app; nessuna QA Vercel necessaria).
• Inviare il RwG Partner interest form (developers.google.com/actions-center/verticals/reservations/e2e/overview) → avvia l'orologio approvazione, zero codice.

Prossimo: (a) a RwG approvato → booking-server = Fase 2 PR2 (feeds Merchants/Services/Availability — riusano getNightlyAvailability/slot — + endpoint v3 REST create/update + HealthCheck); (b) resta accessibile e ad alto valore la PR Finanza "risparmio su dirette" (iCal, modello 3-forme) per avanzare ORA la misura del moat commissioni senza dipendenze esterne. Memory project_booking_channel_hub_2026_06_25 (aggiornata) + project_booking_native_api_foundations_2026_06_29.

---

Chi: Gregorio (mandato: "procedi con Google da browser col mio login; connetti Google Calendar al Booking"; poi "Vercel non pagabile fino a venerdì, procediamo in altro modo"). Claude: setup Google da browser (login founder, non passa da Vercel) + diagnosi outage + spawn chip Calendar.

🔴🔴 OUTAGE VERCEL (verificato 2026-06-29): il team Vercel gregorio-ciurleos-projects è SOSPESO per saldo scaduto (carta 9808) → 402 Payment Required su TUTTA la produzione: multiverbe.app + multiverbe.com + bos.multiverbe.com (questo BOS) + i siti *.multiverbe.app. Anche vercel redeploy = 402. Il 06-25 la landing dava 200 → sospensione scattata 26-29 giu, tolleranza FINITA. Vincolo founder: Vercel non pagabile fino a venerdì 3 lug → prod giù + ZERO deploy fino ad allora. I push git (GitHub) funzionano (codice/BOS preservati); solo i deploy Vercel sono giù → questo commit BOS andrà live venerdì. Azione founder venerdì: pagare https://vercel.com/teams/gregorio-ciurleos-projects/settings/billing → riattivazione ~minuti. Memory project_vercel_outage_402_2026_06_29 (+ pointer in cima a MEMORY.md).

Google infra Pianeta Web — FATTA da browser, tutto consolidato nel progetto GCP multiverbe-2606030125:

• Chiave API PSI/CrUX: creata, ristretta a PageSpeed Insights + Chrome UX Report (least-privilege), VERIFICATA live (PSI perf + CrUX LCP google.com). Su Vercel multiverbe-app: GOOGLE_PAGESPEED_API_KEY + GOOGLE_CRUX_API_KEY (Prod+Dev). → sblocca i pezzi PSI/CrUX della Fase 1 audit (v181).
• OAuth GA4/GSC consolidato: il client OAuth viveva in un ALTRO progetto → creato fresh QUI (consent screen app "Multiverbe", Esterno, Test, email metaverbe@gmail.com; client "Multiverbe Web App" col redirect CORRETTO multiverbe.app/api/oauth/google-callback; utente-test metaverbe@gmail.com). Vercel Production aggiornato GOOGLE_OAUTH_CLIENT_ID/SECRET/REDIRECT_URI al client nuovo; vecchio secret eliminato (1 solo secret, pulito). 5 API abilitate (PSI, CrUX, GA4 Data, GA4 Admin, Search Console).
• Verifica app Google · PREP fatta: scope analytics.readonly + webmasters.readonly registrati + branding completo (home/privacy[200]/termini[200]/domini multiverbe.app+.com/email). ⚠️ NON inviabile in stato Test → si attiva PUBBLICANDO (Test→Prod), da fare quando il flusso "Connetti Google" è live (esiste già in SettingsPage.tsx) → publish + submit verifica = venerdì dopo il redeploy. Serve founder: logo ≤1MB + video demo ~1min (registrabile venerdì) + conferma domini in Search Console. NB: la verifica gata SOLO il collegamento GA4/GSC del cliente esterno; l'audit gira su segnali pubblici senza → non blocca il lancio.

Google Calendar ↔ Booking sync (2-way) · avviato (founder "sincronizza tutto"): Google Calendar API abilitata + scope calendar.events + calendar.freebusy aggiunti al consenso → la verifica di venerdì copre 4 scope in UNA review sola. Scope minimi apposta (events=scrive l'evento-prenotazione, freebusy=legge solo occupato/libero, NO calendar full/readonly). CODICE = chip task_5403c096 (born-green, ships venerdì): estende OAuth (provider google_calendar) + evento su prenotazione (widget-create/create/cancel, colonna GATED bookings.google_calendar_event_id) + blocco slot via freeBusy.query (funzione pura testata) + pulsante "Connetti Google Calendar" in SettingsPage. Fail-soft (mai bloccare la prenotazione).

Batch di venerdì (Vercel pagato): (1) verifica prod torna 200; (2) vercel redeploy <prod> → attiva client OAuth + env nuove + i PSI/CrUX key; (3) pubblica app Google (Test→Prod) + submit verifica (4 scope); (4) merge+deploy chip Calendar + altri PR pronti del chip hub (#457/#460 ecc.).

Owner: Gregorio (decisioni + pagamento Vercel) · Claude (setup Google + orchestrazione). Stato: Google infra done; verifica + calendar + tutti i deploy GATED su "Vercel pagato venerdì". Memory: project_pianeta_web_epic_2026_06_24, project_vercel_outage_402_2026_06_29.

---

Chi: Gregorio (FASE 2 del QA pre-lancio, dopo i microfix v178: scelto via AskUserQuestion "EU AI Act + label", poi precisato: "una spunta una-tantum via card per pubblicare SENZA etichetta prendendosi la responsabilità → sembrano più seri; dobbiamo essere completamente conformi NOI e puliti"; poi "costruisco qui ora"). Claude (orientamento + ricerca legale web art.50 + Explore del codice + build + CI).

Reframe (scoperta chiave): l'infrastruttura di conformità era GIÀ nel codice + DB, dormiente (migrations 2026-06-02a/b di una sessione precedente): etichette disclosure it/de/fr/en (content-disclosure.ts), marcatura macchina C2PA+SynthID (content-provenance.ts, content_assets.watermark), gate revisione umana approve.ts (scrive content_audit_log actor_kind='human' + content_items.review_log) MAI cablato, tabelle content_audit_log + legal_acceptances LIVE. L'immagine generata mostrava GIÀ l'etichetta visibile in StepGuarda; il buco era il TESTO (copiato/pubblicato senza etichetta) + l'assenza dell'opt-out.

Grounding legale (web, art.50 applica 2 ago 2026): art.50(2) marcatura MACCHINA (C2PA/SynthID) = dovere del PROVIDER (Multiverbe), invisibile, sempre attiva, NON opt-out-abile. art.50(4) etichetta VISIBILE = dovere del DEPLOYER (il titolare); per il TESTO si applica solo a "informazione del pubblico su questioni di interesse pubblico" (il marketing PMI tipico NON lo è) e ha l'EXEMPTION esplicita: "non si applica dove il contenuto AI ha subito revisione umana / controllo editoriale e una persona ne ha la responsabilità editoriale". → l'opt-out del founder È legalmente fondato.

Costruito (PR #460, born-green, required CI verde): (1) etichetta visibile sul TESTO (anteprima + copia) in StepGuarda, oltre a quella già presente sull'immagine; (2) card una-tantum "pubblica senza etichetta · me ne assumo la responsabilità" (+ "Ripristina") → registra la scelta nel ledger legale legal_acceptances (document_type='ai_label_optout', SOLO OWNER); (3) in opt-out, soppresse le etichette VISIBILI (testo + overlay immagine), la marcatura MACCHINA resta SEMPRE → Multiverbe conforme a prescindere. Helper puro withAiDisclosure (5 test) + endpoint GET stato / POST owner-only (fail-soft) + hook useAiLabelOptOut. Migration 2026-06-29a (additiva: +'ai_label_optout' al CHECK di legal_acceptances) APPLICATA via MCP + verificata.

CI: required tutti verdi (Typecheck+build, Frontend gate = lint/knip/depcruise/test, Semgrep SAST, gitleaks/trufflehog/trivy/audit). Rossi NON-required ESTERNI (confermati dai log): RLS-isolation + types-drift falliscono su Supabase Management API 401 (token CI scaduto), Vercel su "account blocked" (fattura). mergeable=UNSTABLE (required pass). pnpm install worktree EPERM → CI = gate.

Owner: Gregorio. Stato: PR #460 aperta, required verde, migration applicata. Merge = founder (feature di compliance/liability; la QA live non è possibile finché Vercel è bloccato dalla fattura). Azioni founder: sbloccare Vercel (fattura) per la QA live del flusso Content → card opt-out; poi merge. Memory: project_qa_prelancio_2026_06_25.

---

Chi: Gregorio (mandato design 2026-06-25, evolve v167/v168: costruire l'External Site Hub fase per fase, gancio per primo, autonomia piena). Claude: orientamento sul codice reale → build born-green → verifica gate locali + CI.

Cosa: il primo pezzo dell'External Site Hub. Il gancio: l'imprenditore incolla l'URL del suo sito ESISTENTE e Multiverbe lo analizza dall'esterno, senza migrarlo. Restituisce due voti (Salute SEO + Salute AI Search) e una lista prioritaria di cosa migliorare (impatto × sforzo), in italiano, con "perché conta" + "come si risolve". È il primo passo della tesi "Tieni il tuo sito, Multiverbe lo fa vivere".

Come (architettura): POST /api/web-hub/audit {url} → motore server-side api/_lib/web-hub/audit/* (cheerio + il safe-fetch SSRF-hardened già esistente): scarica la home + sonda robots.txt/sitemap.xml, estrae i segnali on-page (title/meta/canonical/OpenGraph/hreflang/H1-6/JSON-LD/alt/link/viewport/noindex), calcola i punteggi (Salute AI Search = accesso bot AI GPTBot/PerplexityBot/ClaudeBot + schema + struttura answer-ready) e genera i findings ordinati per severità. Parser robots.txt RFC-9309. Contratto puro in src/lib/web-hub/audit/types.ts (condiviso col futuro report UI; api→src permesso, mai il contrario). Route: Bearer auth + membership + rate-limit 12/min IP + persistenza best-effort (l'audit è sempre calcolato e restituito anche prima della migration). Dep nuova: cheerio (server-only).

Dati: migration 2026-06-29a_external_site_audits (RLS workspace-scoped, GATED). ⚠️ rinominata da 2026-06-25a per collisione con 2026-06-25a_booking_crm_contact_link (#450, già applicata): in una sessione lunga (più resume) master era avanzato di 16 commit → ri-verificare il suffisso libero su master prima di fissarlo.

Qualità: born-green in locale + CI: Typecheck+build ✓, Semgrep SAST (RLS+IDOR+SSRF) ✓, Install ✓, Commitlint ✓, TypeScript strict ✓, vitest 1741 (42 nuovi), eslint 0 + knip + depcruise + esm + leaks + madge. Rossi residui = esterni e noti: Vercel "Account is blocked" (outage 402 fino a ven 3 lug) + RLS-isolation/schema-drift (token SUPABASE_ACCESS_TOKEN 401 in CI, non-required).

Cosa NON c'è (incrementi deliberati): PSI lab + CrUX field (gated GOOGLE_PSI_API_KEY); crawl multi-pagina su QStash (oggi solo home sincrono); reweight fix sul traffico reale GA4/GSC; spiegazioni AI + auto-fix Sonnet (dove abbiamo write-access); UI white-label nella cabina "I miei siti" + PDF mensile + link condivisibile = PR2.

Azioni founder: (1) merge #457 (required Typecheck+build verde; gli altri rossi sono esterni); (2) applica migration 2026-06-29a_external_site_audits + regen supabase.ts; (3) Google PSI/CrUX key + OAuth GA4/GSC su Vercel (Fase 1 degrada coi soli segnali pubblici senza); (4) sblocca Vercel (carta 9808, outage in corso).

Prossimo: PR2 = UI white-label del report (cabina "I miei siti", consuma types.ts). Poi PSI/CrUX → spiegazioni AI → Fase 2 (AUMENTA: endpoint pubblici lead/newsletter → CRM + widget vestiti col brand). Memory project_external_site_hub_fase1_2026_06_29.

Owner: Gregorio (decisioni) · Claude (esecuzione + onestà)

---

Chi: Gregorio (epic: "Multiverbe connessa a Booking.com/terzi → sa quando si può prenotare; slot liberato altrove → libero sul sito; Finanza sa dirette vs OTA-con-commissioni"). Claude: ricerca web 2026 obbligatoria + 3 decisioni via AskUserQuestion + build born-green.

Ricerca 2026 (la realtà restringe lo scope): le API native sono inaccessibili pre-revenue — Booking.com Connectivity ha le registrazioni nuovi partner sospese; Airbnb API è invite-only; Reserve with Google richiede partnership + booking-server ospitato. L'iCal (.ics) è l'unico path senza partnership ed è lo standard lodging-only (notti): ristoranti/saloni non hanno controparte iCal (OpenTable/TheFork/Treatwell = API-only). Commissione Booking.com all'hotel ~15% (CH 12-15%; sentenza svizzera −25% sotto ricorso, non in vigore). → Moat "zero commissioni" misurabile come risparmio sulle DIRETTE (l'iCal non porta il valore OTA, solo l'occupazione), modello a 3 forme (pct / fee-a-coperto / %-solo-nuovo-cliente).

Decisioni founder (AskUserQuestion): (1) Target MVP = hotel/B&B a notti; (2) Scope PR1 = import + export two-way (loop completo); (3) Finanza commissioni = PR dedicata DOPO.

Cosa (PR #453, 17 file): tabella booking_channels (per-ws, RLS planet-gate booking, URL import .ics cifrato pgp_sym_encrypt come oauth_connections, RPC service_role-only) + booking_slots esteso (channel_id+external_uid, occupazione OTA = blocco is_blocked). Import = cron 2h che polla gli .ics (SSRF-hardened safe-fetch, dedup per UID, cancellazione = UID sparito, fail-soft). Export = feed .ics pubblico tokenizzato no-PII. getNightlyAvailability esteso per leggere i blocchi (era la lacuna: non li leggeva → niente double-booking cross-canale). Parser/generatore iCal PURI testati (RFC5545). UI Osservatorio in Impostazioni Booking (solo servizi a notte).

Verifica: required CI verde (Frontend gate = lint+typecheck+build+knip+depcruise · Semgrep SSRF/RLS/IDOR · Trivy · secret-scan). Migration applicata prod + verificata (5 policy + 2 RPC, advisor security 0-new). 2 red non-required: types/supabase.ts↔prod (types non rigenerati, drift advisory) + RLS isolation (= 401 Unauthorized: SUPABASE_ACCESS_TOKEN secret scaduto, infra repo-wide non legata a questa PR → founder: ruotare il token nei GitHub secrets). Verifica E2E reale (preview/prod) richiede un URL iCal vero (export Airbnb/Booking.com o calendario pubblico di test).

RESIDUI: merge #453 (founder) · verifica E2E preview · PR Finanza "risparmio commissioni su dirette" (estende l'epic Finanza) · Fase 2 = API native a volumi · founder: ruotare SUPABASE_ACCESS_TOKEN. Memoria: [[project_booking_channel_hub_2026_06_25]].

---

Chi: Gregorio ("sole identity si rinomina in businessidentity ... fallo ora con agenti per sicurezza, poi chiudiamo aggiornando tutto"). Claude (rename deterministico + 2 agenti di audit indipendenti + gate + merge).

Cosa: il modulo identità del cervello AI si chiamava sole-identity (eredità del nome interno "Sole", già rimosso user-facing in v172/#440). Rinominato in business-identity per coerenza: api/_lib/sole-identity.ts → business-identity.ts (+ 2 test), simboli SoleIdentity/loadSoleIdentity/buildSoleIdentity/soleIdentityPrompt/SoleSurface/SoleRole → Business*, script parità check-sole-identity-parity.mjs → check-business-identity-parity.mjs + package.json (check:business-parity) + .github/workflows/frontend-ci.yml, commenti interni "Sole" → "Multiverbe" nei file rinominati. Zero cambiamenti funzionali. Invariati di proposito: sole-ask/sole-actions/sole-crm-suggestions (fuori dallo scope -identity), il testo del preambolo + le ancore del voice-contract (la parità verifica gli stessi 16 invarianti).

Verifica "con agenti per sicurezza" (richiesta founder): 2 agenti di audit indipendenti (completezza repo-wide su ogni file/config/CI + integrità import/simboli su tutti i ~19 importer) → PASS; parity script verde (16 ancore); typecheck:api (oracolo del rename, api/) + vitest 1729 pass verdi; 0 leftover repo-wide. Il build src completo è verificato in CI (l'install worktree locale mancava deps maplibre non correlate al rename → CI = gate autoritativo, lezione v173/v174).

RESIDUI: merge #452 a CI verde. Memoria: [[project_brand_voice_epic_2026_06_25]].

---

Chi: Gregorio (continuazione QA v172, chip task_4526d5b6: "prima i bug/microfix sicuri in autonomia, poi chiedi per il resto; controlla SEMPRE le sessioni concorrenti"; in coda: "il copy satelliti rivedi, modelli nuovi + multilingua, non 'italianizza'; metti in prod + segna su BOS"). Claude (orientamento + verifica live codice/DB + 4 microfix, ordine confermato via AskUserQuestion).

Concorrenza controllata: le PR aperte (#443/#445 booking, #444 brand-voice, #439 Finanza, #433 outreach, #415 content) NON toccano i file dei microfix → 0 duplicazione. Il #1 critico del QA (form prenotazione morto) era già risolto in #438 (v170): saltato.

Verifica > assunzione (finding QA imprecisi corretti sul reale):

• Webhook Stripe upsertSubscription (#449): il finding diceva "onConflict senza constraint", falso. subscriptions ha DUE unique (stripe_subscription_id E workspace_id). Bug vero: su ri-sottoscrizione (stesso workspace, nuovo id Stripe) l'upsert con target stripe_subscription_id va in INSERT → viola UNIQUE(workspace_id) → 500. Verificato live: i 2 workspace reali hanno stripe_subscription_id=NULL → col vecchio codice la PRIMA sub reale li avrebbe 500-ati. Fix = onConflict: 'workspace_id' (invariante 1 sub/workspace).
• Cost-cap status-aware (#449): getWorkspaceTier leggeva plan_tier ignorando lo status → un abbonamento canceled/incomplete teneva i cap del tier alto = leak costo AI/email. Fix: solo active/trialing/past_due danno i cap, il resto → floor 'starter'. Verificato live: i 2 ws reali sono active → nessun declassamento del dogfooding.
• Tab Pagamenti morta (#449): BillingTab chiamava le Edge Function Stripe create-checkout-session/create-portal-session, 0 Edge Function deployate (verificato list_edge_functions) → bottoni morti. Ricablati agli endpoint REST vivi /api/stripe/* via useCheckout/usePortal. Setup-fee display invariato (territorio v171).
• Copy satelliti (#451, reframe founder): le card 3D mostravano codename modelli/marchi (Kimi K2.6, Gemini 2.5 Flash, Mistral EU), vietati verso l'utente (#440) e stale (stack v166/v177), + gergo inglese (funnel, churn, Win rate, KPI, Cold Outreach, burn). Tolti i codename del tutto (zero manutenzione al cambio modello) + gergo → copy piano via skill multiverbe-copy. Web/Booking/Content/CRM/Sales + 1 riga Finanza; Marketing già fatto in #440. Solo display (id stabili) → 0 regressioni; stringhe sorgente per l'epica i18n DE.

FATTO: 2 PR born-green. #449 (billing) MERGED (squash 55d14a3) + #451 (copy) MERGED (squash e67d16e), entrambe a CI verde (Typecheck+build, Frontend gate, Semgrep/Trivy/gitleaks, Vercel deploy), mergeable CLEAN → in prod su multiverbe.app. pnpm install nel worktree EPERM-bound a ore (lezione v173) → CI = gate autoritativo.

Backlog v172 residuo = FASE 2 (lavori grossi, founder decide via AskUserQuestion): CRM Loyalty + lifetime_value senza motore [HIGH]; EU AI Act art.50(4) label "generato con AI" + gate revisione umana [HIGH]; i18n full DE (dashboard scheletro, 0 componenti usano t()); booking tab/widget model-aware (RINVIATO: collide con #443/#445); web-gate over-promise; PII nomi propri liberi alla chat→Anthropic US; perf 58 FK senza indice + 2 policy SELECT permissive. Regression guard anti-slop da estendere a componenti/onboarding (vietare codename modello/marchi nelle stringhe utente).

Owner: Gregorio. Stato: entrambe in prod, nessuna azione founder obbligatoria. Prossimo: FASE 2 = scegliere col founder i lavori grossi. Memory: project_qa_prelancio_2026_06_25 aggiornata.

---

Chi: Gregorio (continua l'epica "stack LLM stato dell'arte 2026" · NORD = miglior sistema di generazione siti al mondo · «procedere fino a completamento e chiudere aggiornando tutto»). Correzione design in corsa (sotto). Claude (PR2 + wrap-up).

Esito sessione:

• PR1 MERGED (#441, squash ecbfc6d) — foundation env-pinnabile: Gemini 2.5→3.5-flash, Mistral medium→large-2512 (Large 3 più forte E più economico), cachedInputTokens esposto, blocco MODEL STACK in .env.example (aggiornare un modello = 1 env var). Kimi resta k2.6.
• PR2 Nano Banana DONE — #448 (MERGEABLE/CLEAN, born-green via CI, merge = founder): migrazione immagini Imagen → Gemini image "Nano Banana" (Vertex Imagen chiude 17 ago 2026). Nuovo adapter :generateContent (vs Imagen :predict); vertex-imagen-fast-eu→gemini-3.1-flash-image (Nano Banana 2), vertex-imagen-eu→gemini-3-pro-image (Nano Banana Pro, SOTA text-rendering = percezione premium hero). Dispatcher instrada per prefisso del modello effettivo → rollback a Imagen = 1 env var, zero deploy. SynthID nativo, EU residency, fail-closed mantenuti; id provider legacy mantenuti (stabilità telemetria).

⚠️ Correzione founder al design (vincolante PR3): NIENTE "premium" universale né multiverbe-design-system/Osservatorio sui siti clienti (= identità di MULTIVERBE, non loro). Il design dev'essere il migliore PER QUEL cliente nella SUA categoria e zona (trattoria di quartiere = la migliore trattoria di quartiere, non lusso fuori posto; fine-dining = il miglior fine-dining). Maestria codificata DENTRO le constitution per-settore (mood specs esistono) + calibrata sul posizionamento (tenant_choices). Reference = leader REALI di categoria/zona, non "siti premium" generici. Tool/modelli top per tutti su qualità immagine/QA; ESTETICA calibrata sul cliente.

Stack web-determinato (no trial a pagamento, da benchmark): design/art-direction=Opus 4.8 · ragionamento visivo=Gemini 3 Pro · copy IT=Sonnet 4.6 (Kimi rimosso) · QA-gate copy=Opus 4.8 (judge) a TUTTI i tier · immagini=Nano Banana Pro/2 · QA visiva=giuria Gemini 3 Pro + Opus 4.8 · loop perfezione visiva Playwright (soglie Lighthouse/axe/CWV, mobile-first 390px).

Pending (handoff): PR3a model-swap (Kimi→Sonnet 4.6, opus-4-7→4-8, fix cost-bug · pronto, zona src/lib/site-design esclusa da tsc → test=oracolo) · PR3b loop visivo Playwright + design contestuale nelle constitution + giurie · PR4 cascata+model-as-judge · PR5 cron run_hour configurabile · efficienza (col cache_read in agent_runs, Batch API −50%, semantic cache). POST-MERGE PR2: allineare canon/05-stack (Imagen→Nano Banana) + verifica id GA Vertex Model Garden.

⚙️ Lezione: pnpm install nel worktree NON popola node_modules (.pnpm pieno ma link top-level fallisce, sia isolato sia hoisted → root cause HDD D:+Defender, cfr project_dev_install_speed_fix). CI è il gate: born-green-by-construction → push → CI verifica su Linux. PR2 chiusa così.

Owner: Gregorio. Stato: PR2 #448 attende merge founder. Memory: project_llm_stack_2026_epic_2026_06_25.

---

Chi: Gregorio (a fine sessione: «mi confermi che QUALSIASI sito generato/esterno → le prenotazioni finiscono sempre e per tutti nel Pianeta Booking e poi nel CRM?» + «se mancano connessioni studiamo a fondo e generi un chip» + «assicurati che il prompt punti a VALORE ESTREMO per tutti gli utenti» + «fai anche la bonifica dei warning»). Claude (verifica sul DB prod invece di confermare alla cieca + chip + bonifica + BOS).

Audit connessioni (verità DB prod, NON assunzioni):

• booking → Pianeta Booking (bookings): ✅ sì, per tutti (28 booking reali; condizione di design: il sito ha la sezione booking + il workspace ha servizi configurati, altrimenti "chiamaci"). Copre anche hotel/B&B (#443).
• booking → CRM: ❌ GAP TROVATO. bookings.crm_contact_id è SEMPRE NULL (0/28): nessun upsert in widget-create/create.ts, nessun trigger DB, Inngest dormiente. Le viste valore (customer_value_v) aggregano per crm_contact_id → il cliente che prenota NON entra nel CRM e il suo valore non è contato. Non potevo confermare "poi CRM": era falso.
• siti ESTERNI agganciati → booking: ⏳ non ancora (è la Web Hub epic separata; erediteranno il flusso quando passeranno per widget-create/ingest).
• notifiche nuova prenotazione: ✅ campanella in-app SEMPRE (il registro: il titolare vede tutto) + push disattivabile (notify_booking_new per-evento + push_enabled + quiet hours). Push fanout gated da env founder.

Chip generato — booking→CRM con VALORE ESTREMO per tutti (task_b1649e3b avviato; brief rinforzato + framing nella memoria project_booking_site_wiring_gap_2026_06_24): ogni prenotazione (qualsiasi sito/settore/tier/sorgente, nessuna allowlist) crea un contatto cliente RICCO che l'azienda possiede per sempre → alimenta valore/LTV + loyalty + churn/retention + segmenti marketing + win-back, coordinato dal Sole. È il MOAT, non plumbing. Approccio preferito: trigger DB SECURITY DEFINER (copre tutte le sorgenti) + backfill 28 + GDPR (marketing consent separato). Web research SOTA (Shopify/Square/HubSpot transactional→customer record).

Bonifica warning ESLint — PR Multiverbe#446 (MERGED, born-green): warning advisory 14→6 (0 errori). Rimossi dead var (formatAddressLine/origin), postcss default anonimo→const, @next/next/no-img-element→OFF con rationale (il runtime usa <img> con srcSet responsive dalla pipeline asset + host CDN arbitrari; next/image non si adatta → scelta corretta, non FP). Restano 6 warning intenzionali set-state/exhaustive-deps.

Owner: Gregorio. Stato: 3 PR di sessione MERGED (#438 booking wiring + giro prod reale, #442 ESLint Next16, #446 bonifica). Chip booking→CRM avviato. Azione: nessuna immediata; il chip costruirà il collegamento CRM. Memory: project_booking_site_wiring_gap_2026_06_24.

---

Chi: Gregorio («risolvi tutti i blocchi e procedi in autonomia con tutti i merge così nulla è lasciato indietro» + «genera un chip per le prossime sessioni» + «procedi anche con la migliorativa»). Claude (merge autonomo + migliorativa + chip).

Esito (chiude v173): le 2 migliorie booking + la migliorativa sono MERGED in autonomia (admin-squash; #443 era BLOCKED da branch-protection → --admin): #445 (segnale dashboard) + #443 (hotel/nightly) + #447 (verifica LIVE di raggiungibilità, born-green primo colpo). Prod deploys app+sites partiti.

Migliorativa #447: 3° check siteReachable al segnale — ping best-effort della route di prenotazione sul sito pubblicato (host fisso .multiverbe.app + slug validato → Semgrep SSRF pass), fail-soft null su 429/errore (no falsi allarmi), solo false conclamato → giallo "il sito non risponde". Cattura "configurato MA rotto", non solo "configurato" (modello Vercel/Stripe).

ESLint flat-config Next 16 (sites-runtime) che il founder aveva messo come prossimo passo = GIÀ FATTO da #442 (mergiato in master durante la sessione, da worktree parallelo, coi preset flat ufficiali eslint-config-next). NON rifatto; verificato che il codice nightly di Task B passa (eslint . = 0 errori; 3 warning non-bloccanti idiomatici).

CHIP nuovo task_5ac395d5 (epic futura): connessione Multiverbe ↔ canali terzi (Booking.com/Airbnb/OTA + iCal) per disponibilità real-time bidirezionale (uno slot liberato altrove torna prenotabile sul sito, e viceversa, senza double-booking cross-canale) + attribuzione della sorgente (sito-diretto = 0 commissioni vs OTA = commissione) → il futuro Pianeta Finanza misura il risparmio commissioni (moat "zero commissioni" reso quantificabile). MVP consigliato = iCal two-way (gratis, niente partnership). Idea del founder.

RESIDUO founder: solo Visual QA post-merge su prod (Chrome MCP) delle 3 variant nightly su un sito hotel reale + della card. Memoria: [[project_booking_site_wiring_gap_2026_06_24]].

---

Chi: Gregorio (epic "Brand Voice qualità massima + auto-miglioramento", chip continuazione). Claude (review del WIP precedente non verificato + quality-pass vs ricerca 31 settori + verifica gate + merge + migration + allineamento a #440).

Cosa va LIVE: ogni titolare ha una voce di brand di default per il suo settore + una scelta di 4 archetipi di tono (consigliato per settore, con esempi), collegata al generatore AI cross-pianeta (outreach + contenuti) da un unico innesto in api/_lib/sole-identity.ts (loadBrandRules fail-soft + renderBrandRules per-surface: EMAIL_TECHNIQUE/WINNING_PATTERN solo outbound; BRAND_VOICE/FORBIDDEN/COPYWRITING_RULE outbound+content; cockpit pulito; cap 14; default-empty = byte-identico). Tono = entity_profile.personality.tone_key (4 archetipi 1:1, nessuna migration). Libreria per-settore (31 settori): frasi vietate, oggetti email, note copy + vincoli legali (sanità art. 321 CP / LSan TI 70, deontologia, PBV prezzi CH). Seed idempotente / non-distruttivo / fail-soft.

Quality-pass aggiunto al WIP: ripristinati tutti gli accenti IT nei 31 settori (era "E ora"→"È ora", qualita→qualità, martedi→martedì); 2 archetipi riallineati alla ricerca (studio-registrazione→casual, agenzia-comunicazione→direct); passati dal lens multiverbe-copy (0 em-dash). Allineato a #440 (v172): UI user-facing "Sole"→"Multiverbe".

Eseguito in autonomia (founder ha autorizzato esplicitamente): merge #444 (squash, born-green: Typecheck+build 2m47s + security suite tutta verde; solo types/supabase.ts↔prod NON-required rosso) · merge #433 (le 3 tabelle outreach config, migration h, già in prod) · migration 2026-06-24i applicata a prod (brand_intelligence.source += 'SEED', verificata: 0 righe, CHECK swappato a MANUAL/ANALYTICS_AGENT/SEED, 0 nuovi advisor).

LEZIONE INFRA (conferma v173): install pnpm worktree patologicamente lento su Windows; PEGGIO — TaskStop NON uccide il figlio pnpm.cjs → i retry hanno accumulato 6 install concorrenti che si auto-bloccavano sullo store; il node_modules del main repo è rotto (typescript/postcss non materializzati). Soluzione per girare i gate in locale: junction del node_modules → un worktree con install COMPLETO (i symlink pnpm sono absolute → risolvono allo store prestato); poi pnpm run <gate> dal proprio worktree (proprio source + deps prestate).

RESIDUI founder / da fare: (1) rename sole-identity → business-identity (26 file + package.json + frontend-ci.yml: refactor coeso a sé stante → handoff a sessione fresca per qualità, non mescolarlo a una feature). (2) check pre-production "imbattibile" finale. (3) PR2 = tono proprio (parla con Multiverbe / mail passate, pseudonimizza PII). (4) PR3 = loop autonomo open-rate (riusa open-tracking #304). Memoria: [[project_brand_voice_epic_2026_06_25]].

---

Chi: Gregorio (chip task_07c98874: "1+2 con estrema qualità + ricerche web per best practice di settore, prenderci il mercato come leader"). Claude (ricerca web 2026 + build + verifica live preview + DB). Follow-up del booking online cablato in #438 (v170).

Metodo: ricerca web parallela su best-practice 2026 (Airbnb/Booking.com/Baymard/NN-g per il booking hotel; Stripe/Shopify/Calendly/Vercel per il "connection health" SaaS) → 2 PR coese separate (progetti + package-manager diversi) → gate + verifica live.

TASK B · soggiorni hotel/B&B (a notte) nel form nativo dei siti — PR Multiverbe#443 (sites-runtime, npm): i servizi a notte (≥1 giorno) erano esclusi → "chiamaci". Ora prenotabili end-to-end. UX check-in-first + stepper notti clampato alle notti davvero libere (Baymard: mai far scegliere una data per poi rifiutarla; ogni combo sempre valida → zero sorprese al submit; riepilogo total-first, orari 15:00/11:00). Helper PURO nightly.ts (14 test), 3 variant preservate, i18n it/de/fr/en. Gate tutti verdi (tsc · vitest 23/23 · next build · eslint · CI Semgrep/Trivy/gitleaks). Verifica LIVE sul preview: availability→mode:nightly+nights[]; create reale (check-in + 2 notti)→201, riga bookings = 15:00→11:00, CHF 240 = 120×2; artefatti di test puliti.

TASK A · segnale dashboard "la prenotazione online è connessa sul tuo sito?" — PR Multiverbe#445 (multiverbe-app): pill verde/giallo/rosso + checklist 2 controlli LIVE + CTA azionabile (modello connection-health Stripe/Shopify). Check: (1) ≥1 servizio attivo; (2) sito pubblicato con sezione booking-widget. Endpoint server-side obbligato: sites ha un RLS planet-gate restrittivo (has_planet_access(...,'web')) → query client dal Pianeta Booking tornerebbe vuota; service-role bypassa, ownership validata al data layer. Derive PURO (8 test), card Osservatorio (LiquidGlass+Badge). Stato validato vs DB reale: demo→verde, workspace Multiverbe (sito non pubblicato)→giallo. CI required tutti verdi (Knip ha pescato 2 tipi esportati-ma-interni → de-esportati).

LEZIONE INFRA (cost-mode): pnpm install nel worktree multiverbe-app è EPERM-bound a ORE (non i ~3 min del CLAUDE.md); junction del node_modules al main repo inaffidabile (worktree nidificato + symlink pnpm relativi). → quando l'install locale è infeasible, CI è il gate autoritativo (un solo run verde non è una catena di fix-commit). Vercel multiverbe-sites correttamente "Canceled by Ignored Build Step" sulla PR app-only → l'Ignored Build Step per-progetto funziona.

RESIDUI founder: merge #443 + #445 (CI verde) · Visual QA post-merge su prod (Chrome MCP loggato) delle 3 variant nightly su un sito hotel reale + della card Task A · i siti generati finora sono di TEST → NON rigenerare. Memoria: [[project_booking_site_wiring_gap_2026_06_24]].

Chi: Gregorio (chip task_4526d5b6: "test rigidissimo come pre-lancio mondiale, prova un po' tutto, capisci cosa manca/rischia/si-puo-migliorare, ripara da solo le rotture, chiedi le cose importanti"). Claude (giro live come owner via Chrome MCP + censimento DB live + workflow review avversariale 10 superfici + 4 decisioni founder via AskUserQuestion).

Metodo: giro reale loggato come owner (workspace Multiverbe, tier Business) su multiverbe.app + censimento DB del workspace dogfooding + workflow ricognizione (10 esperti per-superficie, 64 agenti, verifica avversariale per-finding che ha smontato 1 falso positivo) + verifiche dirette sui finding piu consequenziali.

SOLIDO (verificato, non "sembra"): l'AI "Multiverbe" risponde fondata sui dati reali (identita corretta, tono senza slop); path sole-ask sicuro (auth membership + redactPii + first-name-only + Sonnet + zero DeepSeek/OpenRouter); accensione per-pianeta + seed Booking provato LIVE (acceso Booking sul workspace: seminati opening_hours Lun-Ven + buffer 15 + disdetta 24h + 1 servizio, verificato in DB); motore Booking anti-double-booking + refund #421 corretti; billing Business CHF 249/mese con contatori uso reali; advisor security 0 leak cross-tenant.

RIPARATO in autonomia — PR Multiverbe#440 (born-green, gate verdi): bonifica stringhe customer-facing. (1) nome interno "Sole" -> "Multiverbe" in 12 superfici (founder: "il nome Sole non deve esistere"); identificatori interni intatti (check:sole-parity verde). (2) rimosso il nome modello dall'onboarding ("Sonnet"/"Claude Sonnet 4.6") (founder: nessun codename verso l'utente). (3) anti-slop: en-dash -> trattino, card satelliti Marketing da inglese/gergo -> italiano. (4) CLAUDE.md pricing annuale allineato al canon SSoT (mirror stale ×10 790/1490/2490 -> ×9 711/1341/2241). Gate: build, typecheck:api, lint, depcruise, knip, test 1678, check:leaks/sole-parity/esm tutti verdi.

CORREZIONE (verifica > assunzione): il finding "qualsiasi membro legge i lead (planet-gate Sales neutralizzato)" era SBAGLIATO. Su pg_policies i *_planet_gate sono RESTRICTIVE (AND'd) -> il gate Sales E effettivo (un membro senza accesso al Pianeta Sales NON legge i lead). Nessun buco. Resta solo un advisor perf minore. -> RLS prod NON toccata.

4 DECISIONI founder (AskUserQuestion): (1) annuale = -25% ×9 (codice giusto, allineo le doc) — si incrocia con v171 che RIMUOVE il setup fee: da propagare insieme quando i numeri v171 sono confermati; (2) i18n dashboard = investire sul DE completo (oggi scheletro: 0 componenti usano t(), ~60 stringhe, UI 100% IT hardcoded) -> cantiere dedicato; (3) Web/siti = segnare in BOS per altra sessione (gia coperto: v168 External Site Hub + v170 booking form GIA RISOLTO #438); (4) questa sessione = solo copy + bug sicuri.

BACKLOG "DA FARSI" (net-new da questo QA, non gia tracciato in v167-v171):

• 🔴 CRM Loyalty senza motore + lifetime_value_chf mai popolata: il KPI "VIP a rischio" gira su dati sempre vuoti -> motore che scrive punti/tier/valore, o nascondere i KPI finche non c'e il dato. [HIGH]
• 🔴 EU AI Act art.50(4): testo AI sui social senza etichetta "generato con AI" ne attestazione di revisione umana (approve.ts mai referenziato). Compliance pre-lancio. [HIGH]
• 🟠 Stripe webhook upsertSubscription: onConflict su stripe_subscription_id ma UNIQUE su workspace_id -> rischio 500 (ri-verificare e fixare).
• 🟠 Cost cap non status-aware: abbonato cancellato/unpaid mantiene i cap del tier alto.
• 🟠 Tab Pagamenti (settings) chiama Edge Functions Stripe inesistenti (0 deployate; il checkout principale usa /api/stripe e funziona).
• 🟡 i18n full DE (decisione founder): estrarre le stringhe in i18n + tradurre DE (LanguageSwitcher oggi inerte). Multi-sessione.
• 🟡 Copy satelliti Sales in inglese (Marketing gia fixato in #440): Web/Content/CRM/Booking/Sales descriptions da italianizzare.
• 🟡 Booking: tab "Camere/Tavoli" statico anche per modello "appuntamenti" (label model-aware) · confirm.ts/update.ts senza chiamanti = confermare un booking non avvisa il cliente · widget hardcoded IT.
• 🟡 Web gate over-promise: la checklist promette sito/email/SEO ma l'accensione Web e accensione-only (no seed).
• 🟡 PII nomi propri liberi nelle domande alla chat -> arrivano ad Anthropic US (solo PII strutturata redatta): valutare pseudonimizzazione piu profonda. [decisione da valutare]
• 🟢 perf/scale: 58 foreign key senza indice + consolidare le 2 policy SELECT permissive (advisor) su lead_candidates/sales_icp_profiles. Additivo.
• ⚙️ Regression guard: estendere il guard anti-slop (oggi solo CANON_PLANETS) al copy di componenti/onboarding (vietare "Sole"/"Centro"/codename modello nelle stringhe utente).

Owner: Gregorio. Stato: PR #440 aperta, gate verdi, merge=founder o Claude a CI verde. Report completo consegnato in chat. Memory: project_qa_prelancio_2026_06_25.

---

Chi: Gregorio (in coda alla sessione design External Site Hub: "Multiverbe si paga SOLO in 3 piani mensili; il setup fee non esiste piu; al suo posto un costo PER IL SITO solo se l'attivita non ce l'ha, con 2 opzioni qualita/prezzo, con o senza feature; le modifiche varie si calcolano coi token in piu o pagando"). Claude (cattura + proposta numeri + flag ripple; canon NON toccato senza conferma).

Decisione (evolve/REVERSA il modello pricing del canon):

• Multiverbe = 3 piani MENSILI soltanto (Starter/Pro/Business). Nessun altro asse di prezzo ricorrente.
• SETUP FEE RIMOSSO (oggi nel canon: 590/890/1290 una-tantum). Non esiste piu.
• Al suo posto: costo di CREAZIONE del sito, dovuto SOLO se l'attivita non ha gia un sito (chi COLLEGA il proprio non paga creazione - coerente con l'External Site Hub). Con 2 opzioni di qualita/prezzo (un livello base e uno piu ricco, con o senza feature).
• Modifiche / creazioni varie / aggiornamenti = a TOKEN: incluse entro il cap AI del piano (tier_caps 100/500/2000), oltre = acquisto di token in piu o upgrade di piano.

Razionale: si toglie la barriera d'ingresso del setup (frenava il "collega e prova"), si monetizza il valore ricorrente (piani) + il lavoro reale (creazione sito per chi non ce l'ha, modifiche a consumo). Allineato alla tesi "piu cose vivono dentro Multiverbe, meglio e".

⚠️ RIPPLE da propagare DOPO conferma numeri (founder): canon/03-pricing.md (togliere setup, aggiungere creazione 2-livelli + token top-up), landing copy (multiverbe.com cita il setup fee), Stripe checkout (rimuovere setup one-off, aggiungere prodotti creazione + pacchetti token), tier_caps. NON ancora propagato: servono i NUMERI (i 2 prezzi creazione, il prezzo dei pacchetti token, conferma che i mensili restano 79/149/249).

Owner: Gregorio. Stato: direzione decisa, NUMERI da confermare prima di toccare canon/landing/Stripe. Prossimo: Claude propone i numeri concreti, founder conferma, poi propagazione.

---

Chi: Gregorio (chip dedicato task_53cc70ef, dall'audit: "rendi FUNZIONANTE la prenotazione online sui siti clienti, o fai segnalare le problematiche da Multiverbe"). Claude (build approccio B fino a completamento + verifica live).

Problema: i siti generati mostravano un form di prenotazione MORTO (onSubmit preventDefault, niente workspace_slug) mentre la copy prometteva "conferma immediata" → nessuno poteva prenotare online da NESSUN sito cliente. Blocca la catena dogfooding "il cliente prenota dal sito". Il backend (services/slots/widget-create) era già pronto e live: mancava solo il cablaggio lato sito.

Soluzione (PR #438, born-green): PROXY SAME-ORIGIN. Il form (su {slug}.multiverbe.app) chiama le proprie route Next /api/booking/*, che inoltrano server-to-server a multiverbe.app/api/booking/*. Evita i DUE muri di sicurezza voluti (CORS allowlist statica senza wildcard + X-Frame-Options DENY) senza toccarli: server-to-server non ha CORS, niente iframe niente framing. Upstream hardcoded (no SSRF, confermato dal check Semgrep). Form slot-aware (l'orario si sceglie fra gli slot REALI → niente bug di fuso né prenotazioni fuori-griglia), consenso GDPR obbligatorio, attivazione a runtime (servizi configurati? sì→attivo, no→"chiamaci"; un sito generato a booking spento si accende DA SOLO quando il titolare aggiunge i servizi, senza rigenerarlo). Copy resa onesta (la prenotazione nasce pending, non "confermata subito").

Verifica LIVE (sul deploy preview Vercel del PR + DB prod): create reale attraverso il proxy → 201 → riga bookings pending + campanella al titolare con l'orario nel fuso giusto (verificato via Supabase MCP), poi artefatti puliti. Residuo = solo il giro form-UI cosmetico sul subdomain reale, post-merge.

Owner: Gregorio. Stato: PR #438 aperta, CI tutta verde, mergeable: CLEAN, merge=founder. Azioni founder: mergiare #438; poi un giro UI su trattoria-bellinzona-demo.multiverbe.app. Follow-up: segnale "booking connesso al tuo sito" in dashboard (PR separata) · hotel/nightly nel form nativo (oggi → "chiamaci", nessuna regressione) · rigenerare i siti già pubblicati per assorbire la copy onesta. Memory: project_booking_site_wiring_gap_2026_06_24.

---

Chi: Gregorio (visione 2026-06-24: "Finanza dev'essere uno dei pianeti più importanti e super-intelligenti — da cui si impostano gli OBIETTIVI [stella polare] e Multiverbe, collegata a tutto, lavora coordinata per raggiungerli; andamenti giornalieri; il meglio per ogni settore"; decisioni via AskUserQuestion: obiettivi DENTRO Finanza · "tutto in un blocco" ma soprattutto AI attiva che capisce PERCHÉ non fai più soldi — "hai pochi tavoli / poco personale" — via card proattive). Claude (orientamento + ricerca web SOTA + piano fasato + PR1 born-green).

Visione e modello: Finanza = centro di comando finanziario. Gli obiettivi sono la stella polare che guida gli altri pianeti; il Sole diagnostica il collo del momento in chiave economica e lo spiega ("non cresci perché [collo]") con la leva cross-pianeta giusta. Regola d'oro = integra, non duplica.

Scoperte chiave (verificate in prod):

• Esiste già planet_goals (modello obiettivi cross-pianeta: target_planets[], ai_strategy, provenienza), RLS ok, 0 righe, mai cablato (lo stub legge per errore ai_goals inesistente) → si ADOTTA invece di creare finance_goals.
• I ricavi sono già nel DB (booking total_chf/deposit_paid_chf, deals value_chf/closed_won, crm lifetime_value_chf) → consolidabili senza integrazioni esterne.
• Il growth engine fa già la diagnosi dei colli (detectCapacity=pochi tavoli/personale, detectDemand/Pipeline/Retention); GrowthObjective è il gancio inerte da accendere con l'obiettivo finanziario (PR3 = il cuore della richiesta).
• Connettori esterni (fasi avanti): la Svizzera NON è in PSD2 → gli aggregatori EU (GoCardless/Tink/Klarna) non raggiungono le banche CH (trappola di marketing); via CH = SIX bLink (CHF + ~3 mesi onboarding) o camt.053/CSV (MVP onesto). Stripe = chiave read-only del tenant (NON Connect), API 2026-05-27.dahlia.

FATTO — PR1 "Quadro ricavi" (PR #439, born-green, ZERO migration): nuova vista Quadro nel Pianeta Finanza che consolida i ricavi reali interni (booking realizzato/incassato + deal vinti + LTV) accanto ai costi → margine mensile; KPI di testata Ricavi/Margine; i18n it/de/fr/en; onesto ("ricavi tracciati da Multiverbe"). Gate tutti verdi in locale (tsc api+src, lint 0 errori, vite build, knip 0, depcruise 0, 11/11 test ricavi). Workspace-gated (allowlist Finanza).

Piano fasato: PR1 quadro ricavi ✓ → PR2 obiettivi (cabla planet_goals) → PR3 card diagnostiche (l'obiettivo pilota il growth engine) → PR4 andamenti giornalieri → PR5 per-settore → PR6+ connettori (email→Stripe→banca).

Owner: Gregorio. Stato: PR1 aperta (#439), pronta da mergiare (no migration). Azioni founder: mergiare #439 quando vuoi; le PR future con migration restano gated. Memory: project_pianeta_finanza_epic_2026_06_24. ⚠️ Nota infra: il worktree annidato manda in tilt pnpm install (no-op + lento 9 min) — vedi lezione in memory.

---

Chi: Gregorio (sessione di design dedicata: "pensiamo molto bene COME colleghiamo i siti a Multiverbe per farli vivere dentro · semplifica al massimo per non-esperti · affina tutti i connettori · connetti anche booking e il resto · estrai la direzione visiva se l'utente la vuole tenere · rompi gli standard · poi genera un chip"). Claude (ricerca web SOTA + mappatura del modello di connessione esistente + proposta + AskUserQuestion + chip).

Cosa e cambiato vs v167: la "Fase 1 = audit" si e allargata nel suo vero scopo: l'EXTERNAL SITE HUB, il Pianeta Web unificato ("hai un sito? collegalo · non ce l'hai? te lo creo"). Modello deciso col founder:

• Gancio = OSSERVA & MIGLIORA (audit dall'URL: voto + lista fix; il Sole sistema i sicuri).
• AUMENTA: booking/lead/newsletter dentro il sito esistente -> Booking/CRM/Email Hub.
• MODIFICA: editor AI sul sito collegato (push al CMS via adapter).
• Gemello sovrano SCARTATO (founder: "lo scopo e migliorare; se colleghi il tuo sito e lo modifichi non serve clonarlo"). L'editor-su-sito-collegato sostituisce il gemello.
• Connessione 3 vie (founder "1+3, WP dopo"): snippet universale -> plugin WordPress -> login piattaforma.
• Multi-sito: N proprieta per attivita (.com/.ch/landing/sede2) in una cabina "I miei siti" (unisce sites generati + workspace_external_integrations collegati).
• Impronta del brand (consenso): estrai la direzione visiva -> veste widget + editor + tutti i pianeti.
• Tesi founder: piu cose si fanno e vivono dentro Multiverbe, meglio e (Hub/lock-in).
• PRICING in parallelo (founder decide): prezzare modifiche + creazioni base + aggiornamenti/manutenzione. Proposta in arrivo, NON tocca il canon senza ok.
• Qualita: big-tech, scalabile, production-ready, prompt + sistemi di scanning "top al mondo".

FATTO: generato il chip d'implementazione task_ebd54586 "Costruisci l'External Site Hub (Pianeta Web)" - self-contained, a fasi (gancio per primo), autonomia piena, riuso mappato (mvb.js+ingest dormienti, safe-fetch, Reach, pipeline, tabelle external_integrations LIVE), gate locali completi, prompt+scanning world-class. Memory aggiornata (project_pianeta_web_epic_2026_06_24).

Owner: Gregorio. Stato: design chiuso, chip pronto da avviare. Azioni founder: avviare il chip; decidere il pricing (proposta in arrivo); Google API key PSI/CrUX + OAuth GA4/GSC quando si arriva alla parte connessa; blocker infra Vercel.

---

Chi: Gregorio (decisione founder 2026-06-23 sul gate; poi "assicuriamoci che creare/modificare un sito sanitario sia regolato, con test interni e prompt aggiornabili"; poi "la cosa onesta che hai notato è ottima, fai SEMPRE così" sul buco della modifica-dopo-approvazione). Claude (implementazione born-green + segnalazione proattiva del buco).

Perché conta: per i mestieri della salute (medico/dentista/fisio/psicologo) la comunicazione in CH è ristretta — vietate recensioni/testimonianze (segreto professionale, art. 321 CP), superlativi, promesse di esito, sconti. Noi generiamo e ospitiamo il sito → la responsabilità (anche penale, revFADP, fino a CHF 250k sul founder) ricade in parte su di noi. Servono più strati, non un click vuoto.

Cosa, ora COMPLETO e in produzione (3 PR):

• #427 — gate di pubblicazione (MERGED, migration 2026-06-24e_site_legal_reviews APPLICATA in prod + verificata, advisor-clean): un sito sanitario NON va published senza una revisione legale umana confermata. Data-driven (publishingGate.requiresHumanLegalReview), blocco fail-closed (422) prima di ogni side-effect; tabella site_legal_reviews (RLS scrittura owner / lettura membri, revoca soft); endpoint owner; banner + CTA di firma nel wizard.
• #436 — conformità per costruzione (MERGED, born-green): chiuso un buco reale — la generazione AI iniettava le frasi vietate solo in italiano; in DE/FR/EN ripiegava sui cliché della ristorazione, perdendo i guardrail sanitari multilingua. Ora un modulo SSoT aggiornabile (regulated-compliance.ts) inietta le regole di conformità in ogni lingua, con test interni che bloccano la build se qualcuno toglie una protezione (es. riattiva le recensioni). Zero impatto sugli altri 7 settori.
• #437 — re-invalidazione su modifica (MERGED, born-green, senza migration): il buco onesto segnalato — un sito approvato e poi modificato poteva ripubblicare senza nuova revisione. Ora un'approvazione vale solo se copre il contenuto attuale (firma successiva all'ultima modifica); se il titolare modifica dopo aver firmato, il gate ri-blocca e chiede una nuova revisione.

Verifica: tutti born-green (tsc + build + ~1700 test + lint + knip + depcruise + leaks + Semgrep RLS/IDOR/SSRF + Vercel). Migration #427 applicata e verificata in prod (yqhix); #436/#437 sono solo codice (niente DB). Prod oggi: 0 siti sanitari → gate acceso e dormiente, pronto al primo cliente, rompe nulla.

Owner: Gregorio. Stato: gate sanitario COMPLETO e LIVE su tre strati (non-pubblica-senza-revisione + generato-conforme + modifica-richiede-nuova-revisione). Azioni founder: nessuna su questo fronte (tutto mergiato e applicato). Da farsi (futuro, non urgente): estendere lo stesso pattern di "settore regolato" a finanza/legale quando arriveranno quelle constitution (oggi il segnale isRegulatedConstitution è già pronto); valutare se richiedere una prova della revisione (upload del parere) invece dell'auto-dichiarazione, se vorremo il massimo della difendibilità.

---

Chi: Gregorio (mandato: "porta il Pianeta Web a qualità estrema per stravolgere il mercato", epica multi-PR; "orientati sullo stato reale, ricerca il meglio al mondo, proponimi un piano a fasi e fammi confermare la sequenza prima di costruire"). Claude (orientamento codice+prod, 3 ricerche web SOTA, 2 mappature codice, proposta piano + AskUserQuestion).

Reframe (orientamento verificato su codice reale + prod): il Pianeta Web era GIÀ concepito come "Hub" (founder 2026-05-11/26). Tre vision doc + scaffolding presente: MULTIVERBE-HUB-VISION.md (hub all-inclusive), web-hub/README (foundation A6: lib adapter + useConnectedSites; tabelle workspace_external_integrations/external_widget_configs/external_integration_events LIVE in prod), EXTERNAL-SITES-INTEGRATION.md (agganciare feature Multiverbe a siti esterni via embed/API). Correzioni alla mappa dei buchi (alcuni handoff erano stantii):

• Multilingua = quasi solo UI: la pipeline Stage 3 cicla GIÀ su availableLocales, start.ts accetta/persiste availableLocales/primaryLocale, il runtime renderizza GIÀ it/de/fr/en con hreflang. Manca SOLO lo step "Lingue" nel wizard (oggi parte da ['it']).
• Pixel sovrano GIÀ costruito (dormiente): public/mvb.js (tracker first-party pageview/click/form, consent-gated, sendBeacon) + api/web-hub/ingest.ts (endpoint completo, rate-limited, workspace-validated). Manca: migration web_hub_events (NON applicata), iniezione nei siti, fix gate consenso (legge klaro ma i siti usano la chiave mv-site-consent), UI.
• Cattura lead da costruire: il form Booking dei siti è morto (onSubmit preventDefault) ma l'endpoint pubblico api/booking/widget-create è completo; Contatto = nessun form, Newsletter = sezione assente, zero endpoint pubblico lead/newsletter (la tabella leads esiste).
• Reach internal-only ma primitive riusabili su domini esterni (safe-fetch SSRF, ai-visibility Perplexity Sonar, foundation signals).

Ricerca web SOTA 2026 (3 agenti): (a) Editor AI-native → consenso = direct-manipulation-first + AI secondo layer (Structured Outputs strict, una schema per tipo-blocco, riscrittura di UN blocco, preview accept/reject, site_block_revisions per undo; modelli: Sonnet copy, Opus strutturale, Gemini immagini, Kimi/Haiku palette). (b) Audit esterni → PSI lab + CrUX field = due chiamate (Google deprecando CrUX dentro PSI); GA4/GSC/GBP via OAuth (pattern #335/#381; GBP API già approvata case 7-0288000041625); checklist completa (tech/on-page/schema/internal-links/local/off-page/GEO); prioritizzazione impatto×effort ripesata sul traffico reale; white-label su ogni tier; safe-crawl hardening (DNS-pinning + re-valida ogni redirect + content-type allowlist + byte cap). (c) GEO → base già top-decile; il "+" reale = statistiche+fonte+citazione nel contenuto, answer-first 40-60 parole sotto heading a domanda, schema Service/areaServed/priceRange/FAQPage-da-contenuto-reale, localize (non translate); llms.txt = teatro (tieni, non investire); la leva #1 (menzioni off-site) vive in CRM/Marketing.

3 DECISIONI founder (via AskUserQuestion):

1. Fase 1 = AUDIT siti esterni: URL → crawl + PSI lab + CrUX field + GA4/GSC connessi + Reach Score esteso a dominio esterno → report white-label + fix list impatto×effort. Il differenziatore, prima del resto.
2. Analytics dei siti pubblicati = PIXEL SOVRANO (mvb.js, già costruito, dato 100% nostro, zero costo per-evento, on-thesis). NO PostHog nei siti (PostHog resta solo per il prodotto-dashboard, dove è già attivo). NO Plausible.
3. Sequenza dopo la Fase 1 = come proposto: Editor AI-first → GEO estremo → constitution mancanti, con Analytics (pixel sovrano) dove serve a misurare il dogfooding. Il resto = backlog "da fare" (sotto).

Roadmap Pianeta Web (backlog "da fare", ordine confermato):

• 🔵 Fase 1 · AUDIT siti esterni (IN CORSO) · riusa safe-fetch/Reach/ai-visibility · founder-gated: Google API key (PSI/CrUX) + OAuth GA4/GSC.
• 🟠 Fase 2 · Conversione + Multilingua (DA FARE, è la P0 reale di conversione) · cabla booking (proxy same-origin → widget-create) + costruisci form contatto/lead + newsletter → CRM/Booking/Email Hub + notifica titolare · step "Lingue" nel wizard (backend pronto) → DE/FR/EN.
• 🟠 Fase 3 · Editor AI-first (DA FARE) · manipolazione diretta + assist AI scoped · migration site_block_revisions.
• 🟠 Fase 4 · Analytics pixel sovrano + tag + connettori (DA FARE) · migration web_hub_events+oauth_tokens · inietta mvb.js consent-gated (fix chiave consenso) · UI · connect GA4/GSC/GBP.
• 🟠 Fase 5 · GEO estremo (DA FARE) · stats+fonte+citazione, answer-first, schema Service/areaServed/FAQPage-reale, localize.
• 🟠 Fase 6 · Settori mancanti (DA FARE, parallelo) · 13/21 constitution gold (oggi 8/21).
• (laterale) Aggancio/attach widget a siti esterni (embed/API) · scaffolding parziale · post-audit.

Owner: Gregorio (decisioni + dogfooding). Stato: Fase 1 avviata (PR born-green in arrivo). Azioni founder: per la Fase 1 completa serviranno Google API key (PSI/CrUX) + OAuth GA4/GSC su Vercel (l'audit funziona in degrado con i soli segnali pubblici finché non ci sono); blocker infra invariato (pagamento Vercel carta 9808 → la prod regge in tolleranza). Le migration delle fasi successive (web_hub_events, oauth_tokens, site_block_revisions) restano gated.

---

Chi: Gregorio (mandato: capire i costi totali AI reali del dogfooding; aggiornare i modelli — "Opus è all'8, fai un giro sul web per Kimi/Gemini/Mistral"; "le AI al meglio in assoluto per TUTTI i piani, differenzia sul volume, taglia i token, big-tech style"; "Fable lasciamo stare"; "un solo chip finale"; orario cron configurabile; "fammi domande/consigli"). Claude (misurazione DB + ricerca web 5-agenti + bump + chip).

Costi AI REALI misurati (agent_runs, 22gg, ~5 workspace attivi): Sonnet 4.6 ~$5.75 + Opus 4.7 ~$3.51 = ~$9.3 totali → ~$2-4/utente/mese per il cervello del Sole (driver: cron analyze_planet_data + strategist Opus; la chat è ~$0.01, quasi inusata). NON in agent_runs: Content (Gemini/Veo video = jolly COGS), site builder (Kimi), outreach (Mistral). La bolletta Anthropic ~€200-400/mese è quasi tutta DEV (Claude Code che costruisce), non l'inferenza per-utente. Margine sano a CHF 79-249; l'occhio va sui video (Veo 8s+audio ~$6/clip).

Ricerca web 2026 (id+prezzi): Opus 4.8 ($5/$25, già nel canon dal 30/5, codice era indietro) · Sonnet 4.6/Haiku 4.5 invariati · Kimi K2.7-Code (kimi-k2.7-code, −30% token, coding-only) · Gemini 3.5 Flash + Nano Banana (gemini-3.1-flash-image; ⚠️ Imagen deprecato shutdown 17 ago 2026) + Veo 3.1 Lite/Fast/Quality · Mistral Large 3 (mistral-large-2512, più potente E più economico di Medium 3.5 — anomalia da verificare) · Voyage voyage-4-large già SOTA.

DECISIONI founder:

1. Fable 5 NON adottato (rimosso dal codice/CLAUDE.md). Top = Opus 4.8.
2. AI migliore IN ASSOLUTO per TUTTI i piani (non modelli scadenti ai tier bassi). Differenziazione = volume (quota/tier_caps) + profondità (effort/verifica) + media premium (scelta via AskUserQuestion). Il costo si controlla con EFFICIENZA (prompt caching −90% system ripetuti, Batch −50% non-real-time, semantic caching, prompt più corti, effort tarato) e cap volumetrici sui media (i video, non il ragionamento già economico), big-tech style.
3. Cascata routing del Sole: Haiku→Sonnet 4.6→Opus 4.8 (no Fable) + model-as-judge sulle azioni ad alto impatto.
4. Cron "giro totale" configurabile dall'utente (ora del giro notturno · memory_settings.run_hour + tick orario + gate per-workspace) — incluso anche se impatto piccolo.

FATTO: bump Opus 4.7→4.8 nel codice (#435 born-green: model-routing + llm-client + subprocessors legale + .env.example + CLAUDE.md; site-builder src/lib/site-design @wip resta su 4-7, migrazione a parte). Tutto il resto (Kimi verify+test, Gemini best-for-all + Imagen urgente, Mistral verifica anomalia, cascata, cron-orario, tiering, efficienza) = UNICA epica in un chip consolidato (task_c2098839); dismessi i 4 chip frammentati.

Nota infra: il "classificatore" che si è inceppato è il safety-classifier del harness Claude Code (usa claude-opus-4-8, era transitoriamente non disponibile lato Anthropic), non lo stack Multiverbe; già rientrato. Leva nel nostro controllo per ridurre gli intoppi: allowlist comandi sicuri in .claude/settings (proposta al founder).

Owner: Gregorio. Stato: #435 in PR (merge a CI verde). Azioni founder: merge #435; eseguire l'epica LLM (chip) quando vuole; decidere allowlist .claude/settings.

---

Chi: Gregorio (mandato: estendere l'onboarding v2 a Sales; poi "chiudi tutto a qualità big-tech in vista di produzione e vendita, così faccio dogfooding fingendomi un'azienda"; autonomia piena fino a prod). Claude (implementazione + apply prod + chip).

Cosa:

1. Onboarding progressivo v2 esteso a Sales (#426 MERGED, vedi v160) e ATTIVATO LIVE in prod su autorizzazione founder: migration 2026-06-23b_planet_setups.sql applicata via Supabase MCP (planet_setups: RLS on, 3 policy owner-write/member-read, 2 trigger, 0 nuovi advisor) + VITE_ONBOARDING_V2=true su Vercel multiverbe-app + redeploy → aliasato su multiverbe.app. Il gate per-pianeta dipende SOLO da planet_setups (che ora esiste) → il progressivo è attivo per gli owner: Booking e Sales seedano davvero (orari/servizio · raggio ICP), gli altri 4 sono accensione-only. NB: nascendo ora planet_setups, anche i workspace esistenti vedranno la scheda "Accendi" una volta per pianeta (UX progressiva voluta, fail-soft + "Più tardi").
2. Chip di chiusura generato (task_c2ed3a75 "Chiudi Multiverbe a qualità big-tech per dogfooding e vendita"): closeout pre-produzione/vendita in 2 fasi sequenziali — (a) giro end-to-end reale per pianeta ("azienda finta" = Multiverbe) con dati veri, zero dati finti, advisor 0, fix dei buchi; (b) hardening big-tech (security/advisor→0, RLS multi-tenant+IDOR, robustezza/osservabilità, Knip/dep-cruiser/bundle/a11y, copy anti-slop, pulizia). Autonomia piena fino a prod (PR born-green → merge a CI verde + migration + redeploy), DoD del charter, metodo ultracode (graphify → grounding DB live → review avversariale → fix). Output atteso: report di dogfooding-readiness per pianeta + BOS/memoria aggiornati.

Owner: Gregorio (decisioni + dogfooding di verifica). Stato: onboarding v2 LIVE su 2 pianeti; closeout delegato al chip. Azione founder dopo il chip: aprire l'app come "azienda finta" e verificare end-to-end. Blocker infra invariato: pagamento Vercel (la prod regge in tolleranza).

---

Chi: Gregorio (richiesta + decisione esplicita sul metodo di recupero: "opzione primaria il dato biometrico, poi frasi di recupero standard di settore big tech"). Claude (progettazione, sviluppo, applicazione in produzione e merge in autonomia su mandato del founder).

Contesto: l'imprenditore deve poter entrare nell'app nel modo più semplice e sicuro possibile. Finora si entrava solo con email e password (più magic-link, Google e Apple). Aggiungiamo l'accesso con il sensore del telefono — Face ID, impronta o Windows Hello — come metodo principale.

Cosa è stato deciso e fatto:

1. Accesso biometrico tramite passkey. La "passkey" è una chiave d'accesso basata sullo standard internazionale WebAuthn (lo stesso delle app bancarie), supportata nativamente da Supabase (il nostro sistema di autenticazione). In pratica: invece della password, il telefono conferma l'identità col proprio sensore. Il dato biometrico (faccia o impronta) non lascia mai il dispositivo: al nostro server arriva soltanto una chiave pubblica, inutile da sola. Questo è più sicuro di una password ed è resistente al phishing (non c'è una password da rubare). Conta anche per la responsabilità del founder (revFADP): non custodiamo nessun dato biometrico sensibile.

2. Recupero "stile big tech", non "stile crypto". Decisione esplicita del founder, dopo aver chiarito un equivoco diffuso: le "frasi a 24 parole" sono lo standard dei portafogli di criptovalute, non delle grandi piattaforme. Google, GitHub e Apple usano i codici di recupero monouso: una decina di codici che l'utente salva al momento dell'attivazione e che servono a rientrare se perde il telefono. Li mostriamo una sola volta; nel database conserviamo solo la loro impronta cifrata e "pepata" (un segreto, il "pepe", che sta nelle variabili d'ambiente di Vercel e mai nel database: così, anche se il database trapelasse, i codici non sarebbero ricostruibili). Ogni codice funziona una volta sola.

3. Dove si usa. Pulsante "Accedi con Face ID o impronta" come azione primaria nella pagina di accesso; gestione completa nelle Impostazioni (attiva la biometria, dai un nome ai dispositivi, rigenera i codici); pagina dedicata per rientrare con un codice di recupero.

Stato: la modifica al codice (PR Multiverbe#425) è stata mergiata ed è in produzione dal 24 giugno 2026. La migration del database è applicata in produzione (verificata: isolamento RLS corretto, nessun dato esposto), le passkey sono abilitate sul cruscotto Supabase e il segreto RECOVERY_CODE_PEPPER è impostato su Vercel. Resta solo la prova finale su un telefono reale (Face ID/impronta non sono testabili in automatico). Riflesso nella Visione Totale come piano infra-auth (grattacielo Applicazione, layer Infrastruttura).

---

Chi: Gregorio ("multiverbe in dogfooding cos'ha in memoria? facciamole imparare… e capiamo se le conversazioni spariscono o restano come i leader"; poi "dare più di quanto diciamo, qualità estrema"; poi "procedi in autonomia su tutte le azioni founder" + "concludiamo tutto con qualità e allinea bos e tutto il resto"). Claude (audit + ricerca SOTA + design + implementazione + apply migration + merge + docs).

Contesto: il Sole imparava SOLO i numeri (cron metriche → entity_memory). Le conversazioni erano write-only (mai distillate, fuori dal recall), niente memoria multi-turno, nessun controllo memoria per il titolare, layer Sector non davvero cross-tenant, Knowledge statico nel codice, e una UI legacy "cervello a 15 livelli" (KnowledgePage) che leggeva una tabella inesistente. Confronto con lo stato dell'arte 2026 (Mem0, Zep/Graphiti, Letta/MemGPT, A-MEM) → diagramma + 4 decisioni founder.

4 decisioni founder: (1) modello a due store (cronologia conversazioni + memoria distillata, come i leader); (2) layer di settore cross-tenant = roadmap dopo i primi paganti (k-anonimato + privacy differenziale + DPIA); (3) memoria ON di default + conversazione temporanea; (4) fatti autoritativi (orari/prezzi/policy) auto-salvati con Undo (revisione, non blocco).

Cosa (3 PR · tutte born-green):

• Fase 0 (#424 MERGED · migration applicate a prod in autonomia): la memoria diventa bi-temporale (valid_from/valid_to/superseded_by → un fatto che cambia si invalida, non si sovrascrive: niente "confidently wrong"), tracciabile per provenienza/confidenza, con gate PII esteso alle categorie sensibili GDPR art. 9 (fail-closed) e audit immutabile (audit_log_memory) + workspaces.memory_settings. Migration 2026-06-24a (bi-temporalità + RPC con filtro valid_to) e 2026-06-24b (audit + settings) applicate via MCP, advisor di sicurezza puliti.
• Fase 1 (#431 MERGED · dormiente): l'agente notturno (Inngest, 03:30 Europe/Zurich) distilla le conversazioni in fatti (Haiku 4.5), con self-edit/dedup bi-temporale (near-dup→skip, fatto autoritativo cambiato→supersede). Gated come lo strategist (NIGHTLY_CONSOLIDATION_ENABLED off, cap, fail-closed) → zero costo finché non lo si accende. Chat real-time invariata (apprendimento asincrono di notte). + flag temporary in sole-ask (conversazione senza traccia).
• Bonifica (#432): rimossa la KnowledgePage/BrainWizard ("cervello a 15 livelli" MAIND · rotta perché legge brand_intelligence inesistente · off-thesis: il nostro utente non riempie categorie a mano, il Sole impara da solo). Sostituta = pannello «La mia memoria» (Fase 3).

Scoperta (task separato · chip): anche BrandVoiceTab, CitiesTab (OutreachConfigTab) e BrandIntelligencePage (Strategia) leggono tabelle inesistenti (brand_intelligence, geography_strategy) → runtime-broken. Sono feature legittime di Sales/Strategia: vanno SISTEMATE (creare le tabelle o ricablare), non rimosse → decisione/lavoro a parte.

Metodo: audit multi-agente (codice + DB live) → ricerca SOTA 2026 (7 agenti) → design con diagramma → confronto founder (AskUserQuestion × decisioni) → plan-first approvato → implementazione born-green (typecheck:api, test, esm, leaks, knip, depcruise, lint, build verdi su ogni PR) → apply migration + merge in autonomia → allineamento docs. LEZIONI: api/ si typechecka con typecheck:api (tsc copre solo src); la RPC pgvector richiede search_path = public, extensions (il file 2026-06-24a va riallineato); fail-soft attraverso il confine migration (colonne nuove scritte solo se il chiamante le passa).

Owner: Gregorio. Stato: Fase 0+1 LIVE (agente dormiente), Knowledge UI rimossa. Azioni founder rimaste: (1) rigenerare src/types/supabase.ts da prod + allineare search_path nel file migration 2026-06-24a (serve SUPABASE_ACCESS_TOKEN); (2) per accendere l'agente: env Vercel NIGHTLY_CONSOLIDATION_ENABLED=1 + cap/modello + budget/kill-switch; (3) merge #432; (4) sistemare le 3 UI con tabelle mancanti (chip). Roadmap memoria: Fase 2 (hybrid retrieval + core block), Fase 3 (pannello «La mia memoria» + DSAR + UI conversazione temporanea), Fase 4 (grafo cross-pianeta), Fase 5 (sector collective). Handoff Fase 1 (ora superato): execution/handoff-2026-06-24-sole-memory-fase1.md.

---

Chi: Gregorio (decisione founder 2026-06-23, follow-up chip #1 di #423: "un sito sanitario NON deve poter passare a published finché non è confermata una revisione legale umana"). Claude (grounding stato reale + implementazione fail-closed + born-green).

Contesto: la 8ª constitution gold-standard = SANITÀ (studio-medico, serve medico/dentista/fisioterapia/psicologo, #423 LIVE) dichiara già il requisito in modo data-driven: publishingGate.requiresHumanLegalReview = true. Mancava l'enforcement. Liability penale founder fino a CHF 250k (revFADP, dati salute categoria particolare) + regime pubblicitario sanitario CH restrittivo per professione (OMCT/OMDCT, US-DSS, FMH/SSO/physioswiss/FSP + art. 321 CP + LSan TI art. 70).

Cosa (1 PR #427, born-green):

• Enforcement in api/site/publish.ts (il seam UNICO verso published; il worker non pubblica; unpublish→re-publish ripassa di qui): legge il publishingGate della constitution del sito e blocca PRIMA di ogni side-effect (Vercel domain, update status, hook Reach). Niente approvazione viva → 422 legal_review_required; gate non verificabile → 503. Fail-closed. I settori non gated non interrogano mai la tabella → zero regressioni sulle 8 constitution.
• Migration 2026-06-24e (GATED): site_legal_reviews (audit con revoca soft) + RLS scrittura solo owner / lettura membri (idioma team_members + (SELECT auth.uid())) + indice parziale. Rebumpata da c→e per collisione con #429 Finanza (merged, ha preso c+d).
• Endpoint api/site/legal-review.ts: GET stato gate · POST approva/revoca solo owner (ownership validata al data layer, authority/constitution snapshottati server-side).
• UI Step7Publish.tsx: banner bloccante "Sito sanitario · revisione legale obbligatoria" + autorità + CTA firma (solo owner, attestazione esplicita); pulsante Pubblica gated finché non approvato.
• Fail-closed by design: finché la migration non è applicata, la tabella non esiste → nessuna approvazione possibile → i siti sanitari restano comunque bloccati (dormiente ma sicuro).

Metodo: grounding stato reale (master + prod: 8 constitution, 31 settori) → seam unico identificato (publish.ts, non il worker) → helper PURI testati + lookup DB fail-closed → born-green locale (typecheck:api · build tsc+vite · test 1567 pass · lint 0-err · knip · depcruise · check:leaks, tutti verdi). CI: tutto verde tranne types/supabase.ts ↔ prod schema = drift ESTERNO #424 (non-required, rosso anche su master); il client publish è untyped → nessun regen tipi richiesto.

Owner: Gregorio. Stato: gate completo, born-green, in PR. Azioni founder: applicare 2026-06-24e_site_legal_reviews.sql in prod (Supabase yqhix) + merge #427 a CI verde. Chip fratelli di #423: #2 tenantChoices UI = PR #428 (parallela); #3 collisione suffisso #421 = già risolto (2026-06-23g).

---

Chi: Gregorio (richiesta: "costruisci l'MVP interno del Pianeta Finanza per il dogfooding su Multiverbe; per ora deve vivere ESCLUSIVAMENTE nell'account/workspace Multiverbe, non esposto agli altri tenant"). Claude (grounding DB live + mappa blast-radius 3D + implementazione + born-green). Bivio UI deciso dal founder via AskUserQuestion: 7° pianeta 3D orbitante (non un pannello separato).

Contesto: il Pianeta Finanza era a 0% di codice. Scopo prodotto (canon): registro vivo dei costi + scadenzario "cosa pago, su quale carta, quando" + allarme carta-che-fallisce. NON cassa/POS né partita doppia. Dogfooding: lo riempiamo coi NOSTRI costi veri (execution/stack-costi-pagamenti.md, verificato 24/6). Vincolo founder ferreo: per ora SOLO il workspace interno Multiverbe.

Cosa (1 PR #429, born-green):

• Migration 2026-06-24c (GATED): finance_payment_methods + finance_cost_entries + finance_enabled_workspaces (allowlist = il gate) + RLS (workspace-isolation AND is_finance_enabled() SECURITY DEFINER) + indici FK/scadenzario + trigger. Advisor-clean by construction.
• Seed 2026-06-24d (GATED): risolve il workspace Multiverbe per owner-email (no UUID hardcoded → robusto/ambiente-indipendente), lo allowlista, inserisce 2 carte (Mastercard •9808 failing, Visa •6073 ok) + ricorrenti/prepagati/domini/pianificate dai dati veri. Idempotente, fail-safe (workspace assente → skip).
• Endpoint api/finance: overview (aggregati puri testati: burn mensile normalizzato annual/12·quarterly/3, breakdown categoria, scadenze 30/60/90 con flag su-carta-che-fallisce, allarmi carta → servizi a rischio, prepagati) + CRUD costi/carte. Guard authorizeFinance: token + membership + allowlist, fail-closed (migration assente → 403).
• 7° pianeta 3D: finanza ∈ PianetaName (17 Record<PianetaName> aggiornati, lo impone tsc) + PIANETI_CONFIG (orbita esterna kepleriana r=9.5) + shader lime + glifo (già pronto) + fallback 2D. Gate workspace-scoped (NON tier): useFinanceEnabled (allowlist, fail-soft) iniettato in 4 punti d'enumerazione (scena visiblePlanets+cycle, sidebar, dot). finanza fuori da NAV_PLANETS/PLANET_TIERS/ALL_PLANETS/CANON_PLANETS → niente upsell tier, niente RBAC per-membro (Loris lo vede). Scena 3D = territorio founder, toccata SOLO perché il founder ha scelto esplicitamente il 7° pianeta.
• UI FinanzaSurface (4 satelliti Costi/Scadenze/Carte/Categorie) · it/de/fr/en · accessibile · KPI di testata reali (burn/scadenza/a-rischio) in pannello + dashboard card.

Metodo: grounding DB live (workspace Multiverbe = b781a7b4…, owner metaverbe@gmail.com) → Explore mappa il blast-radius 3D (Record + scena/nav/fallback/cycle) → implementazione gated + fail-soft → born-green locale (tsc src+api · lint · build · test incl. aggregati · knip · depcruise · check:leaks · check:esm-api, tutti verdi). NON applico la migration né rigenero supabase.ts (evita schema-drift CI · lezione #421); il client usa supabase non tipizzato (come planet_setups).

Owner: Loris (business owner Finanza) + Gregorio (codice). Stato: ✅ APPLICATO E LIVE in prod (stessa sessione 2026-06-24): #429 mergiato born-green + migration c+d applicate via MCP + hardening g (is_finance_enabled → schema private; #430 merged --admin perché DB-only fuori dal path-filter di Typecheck+build). Verificato: solo Multiverbe allowlistato a livello globale (gate tiene), 2 carte, 21 voci reali, burn CHF 278, 6 servizi sulla carta 9808; advisor security 0 ERROR / 0 WARN da Finanza (resta solo il WARN pre-esistente recovery_codes_status, MFA). Resta al founder: (1) rigenerare src/types/supabase.ts (ora che le finance_* sono in prod → chiude il check schema-drift, copre anche il drift MFA pre-esistente); (2) verifica live nel workspace Multiverbe. Apertura clienti ~ago 2026 = INSERT allowlist. Moat post-MVP: import automatico dalle fatture email.

---

Chi: Gregorio (mandato ultracode: "estendi la v2 al prossimo pianeta dopo Booking dove il seed è davvero provabile"). Claude (grounding DB live + implementazione + review avversariale + PR).

Contesto: dopo Booking v2 (#420/#422), il framework "il gate di accensione cattura UNA scelta che SEEDA davvero il pianeta" va esteso al pianeta successivo. Regola ferrea: ogni campo catturato dev'essere realmente letto dal pianeta, provato con un test (niente campi nel vuoto, zero dati finti).

Scelta del pianeta (grounding, non a memoria):

• Content → SCARTATO per ora (resta v1): le tabelle content_plans/content_calendar_events esistono ma non sono lette da nessun codice (solo nei tipi generati); il calendario editoriale (social_posts) si popola dalla generazione manuale, nessun consumatore di una "cadenza" → un seed andrebbe nel vuoto.
• Web → SCARTATO per ora (resta v1): il SiteBuilder non ha un consumatore reale per un "obiettivo del sito" (generazione sector/constitution-driven).
• Sales → SCELTO: catena viva e già testata. Il seed scrive sales_icp_profiles.default_radius_km, letto da api/sales/discover.ts (raggio di ricerca OSM/Overpass) e passato al fit-score puro scoreCandidate come radiusKm (asse vicinanza).

Cosa (1 PR #426, born-green):

• Campo sales_reach sul gate Sales (3 fasce: città 15 km / regione 50 km / raggio ampio 100 km), preselezionato dal settore (suggestReachBand). Semina solo uno scalare reale (il raggio di ricerca dell'ICP), mai industrie/offerte/esclusioni inventate (quelle = profilo del titolare o derive del Sole).
• src/lib/sales/seed-defaults.ts (nuovo): resolver puri + applySalesReachSeed client-side (RLS owner + planet-gate, workspace_id filtrato, fail-soft, supabase in import pigro, Map non Record). shouldSeedIcpRadius: scrive solo su un ICP vergine (niente industrie/offerte, raggio al default, mai derivato) → non distruttivo.
• ICP_DEFAULT_RADIUS_KM = alias dell'unica SSoT RADIUS_DEFAULT (icp.ts) per evitare drift.
• Prova (regola ferrea): test resolver (produce esattamente {15,50,100}, idempotenza) + contratto motore in fit-score.test.ts che fa girare il vero scoreCandidate sui raggi seminati e prova che il motore li legge; planet-setup.test.ts aggiornato al contratto v2 (Booking e Sales hanno un campo) + guardia anti-drift value scelte == SalesReachBand.

Metodo (ultracode): grounding DB live (Supabase MCP: colonne sales_icp_profiles, RLS, nessun trigger di default ICP, entity_profile/workspaces senza city usabile) → implementazione mirror di Booking v2 → review avversariale 4 lenti + verifica per-finding (13 finding → 2 confermati low, risolti: copy "In tutta la Svizzera" prometteva una geografia che un cerchio di 100 km non mantiene → "In un raggio ampio"; costante raggio duplicata → alias SSoT). Gate locali born-green su base rebased su master (dopo #424): tsc src+api, vite build, eslint (0 nuovi warning, 454<560), depcruise, knip, vitest 1575.

Owner: Gregorio (decisioni + merge). Stato: onboarding v2 ora su 2 pianeti (Booking + Sales); Content/Web restano v1 documentati (nessun seed provabile oggi); CRM/Marketing invariati. Azioni founder: merge #426 a CI verde; per testarlo dal vivo applicare 2026-06-23b_planet_setups.sql + VITE_ONBOARDING_V2=true (il gate per-pianeta dipende SOLO da planet_setups).

---

Chi: Gregorio (mandato ultracode + 4 decisioni esplicite via domande: scope = anche fisio+psicologo "ognuno con le sue specifiche perfette"; prezzi = opzioni configurabili non default rigido; ogni scelta = "una domanda per card, minimal, sempre col consigliato per settore"; revisione legale = "gate obbligatorio di pubblicazione"). Claude (orchestrazione agentica in-sessione per stare nel contesto: ricerca → authoring → review → fix delegati a subagent; io orchestro + verifico + apply DB).

Contesto: 8ª constitution dopo hotel (v153). La sanità è il settore a più alta responsabilità penale founder (CHF 250k revFADP): dati salute categoria particolare + pubblicità sanitaria CH restrittiva + segreto professionale. Il founder ha ESPANSO lo scope a 4 professioni.

Cosa (1 PR #423, born-green, squash-merge a CI verde + apply DB prod):

1. Constitution studio-medico (la più ricca di tutte: 105KB JSON / 53kB col). UNA constitution serve 4 sector_id (studio-medico, dentista, fisioterapia, psicologo) come professional-services. schemaOrgType default MedicalClinic; per professione: medico→Physician, dentista→Dentist, fisio→MedicalClinic+medicalSpecialty Physiotherapy, psicologo→MedicalBusiness (MAI Physician/Psychiatric). 13 pageRecipes, 10 sezioni enriched (testimonials/recensioni ASSENTI — vietate), 4 moodSpecs riusati (no edit design-tokens), 8 tenantChoices, 95 forbiddenPhrases.

   • Tipi additivi: SchemaOrgType +MedicalClinic/MedicalBusiness/Physician/Dentist; ConversionGoalType +appointment_booking; SectionType +medical-services/insurance-info/emergency-contacts; PageType +prestazioni/equipe; +publishingGate (gate legale data-driven) +tenantChoices (scelte col consigliato-per-settore — implementa la decisione #3 del founder).
   • 3 NUOVI settori (macro salute 28→31): dentista, fisioterapia, psicologo (+ studio-medico rinominato "Studio medico" medico-only). Sincronizzati su 4 copie anti-drift (catalogo TS + keyword-matcher + SECTOR_WHITELIST + SECTOR_TAXONOMY API) + la 4ª copia DB sectors. I 2 test anti-drift impongono la sincronia.

2. COMPLIANCE = il moat (verificato web giugno 2026): MAI testimonianze/recensioni/aggregateRating — doppiamente vietate: ineleggibili (Google self-review) E illegali in CH (FMH Anhang 2 / SSO / physioswiss / FSP + art. 321 CP). MAI superlativi/promesse di esito. MAI promozioni/sconti (LSan TI art. 70). TARDOC dal 01.01.2026 (mai TARMED). Consenso dati salute esplicito separato + pseudonimizzazione pre-LLM US. Psicologo "non sono medico" + emergenze 143/144/147/112 sempre visibili. Assicurazione per professione (LAMal/TARDOC medico, self-pay+preventivo dentista, prescrizione serie-di-9 fisio, Anordnungsmodell 2022 psicologo). publishingGate: revisione legale umana OBBLIGATORIA pre-publish (OMCT/OMDCT/US-DSS) — decisione #4 del founder.

Metodo (ultracode orchestrato, context-managed): ricerca web 2 pass (5 agenti medico+dentista → brief; 2 agenti fisio+psicologo → brief finale 4-professioni, letti dai subagent) → un subagent autora la constitution 2173 righe → review avversariale 7 assi (compliance 95; cro 88 e type-contract 82 fixati alla radice: recall serie fisio/psico + dentista come settore reale) → un subagent applica i fix → io fix strutturali + apply DB. Round-trip JSON deep-equal.

⚠️ Lezioni: (1) i gate locali vanno fatti COMPLETI (lint+test, non solo tsc+leak): qui un \' inutile + 2 guardie anti-drift erano rosse e solo i gate completi le hanno prese. (2) suffisso migration 2026-06-23f condiviso con booking #421 (non mergiata): nessuna collisione in master ora; chi mergia #421 per secondo bumpa a g.

🟢 DB APPLY LIVE & VERIFICATO: upsert one-off (constitution + 4 settori) → MCP: 53kB, 8 tenantChoices, publishingGate true, 8 constitution active, 31 sectors; advisors 0 nuovi.

Owner: Gregorio (decisioni/canon). Claude (orchestrazione + verifica + apply DB). Stato Site Builder: 8 constitution, sanità copre 4 professioni. Follow-up (chip spawnati): enforcement gate legale publish + UI onboarding scelte (tenantChoices). ⚠️ Blocker invariato: pagamento Vercel (siti = *.multiverbe.app).

---

Chi: Gregorio ("chiudi aggiornando tutto e genera un chip che crei questo pianeta; deve vivere esclusivamente nell'account Multiverbe così io e Loris abbiamo già tutta la contabilità pronta e nel sistema intelligente").

Decisione: il Pianeta Finanza (avviato in v157) per ora vive esclusivamente nell'account/workspace Multiverbe (workspace interno, non esposto agli altri tenant). Generato un chip di build verso il repo prodotto D:\Desktop\Multiverbe con la specifica completa (ops/pianeta-finanza-dogfooding-2026-06-24.md), il seme reale (execution/stack-costi-pagamenti.md) e il vincolo workspace-scoped (gate che impedisce visibilità in altri workspace). Apertura ai clienti ~agosto 2026 invariata. Aggiornati cantiere.json (nota Finanza) e canon/spec con il vincolo di esclusività.

Owner: Gregorio (codice del pianeta via chip, nel repo prodotto) + Loris (business owner Finanza). Sessione BOS chiusa qui.

---

Chi: Gregorio ("aggiorna tutto lo stack dei costi e ricorrenze con dati reali così so cosa devo pagare e quando" + "creiamo già un pianeta finanza e riempilo con tutto ciò che riguarda noi per potenziare il dogfooding; per ora interno, verso agosto disponibile ai clienti") · Claude (verifica carte dai cruscotti + scrittura stack/calendario + spec Finanza).

Cosa 1 — stack costi reale + calendario "cosa pago e quando". Verificato dai cruscotti che gli addebiti sono su due carte: la Mastercard 9808 è MORTA (rifiutata 8 volte) ed è quella di Vercel + Supabase + iubenda + claude.ai (quasi tutta la spesa critica!); la Visa 6073 funziona (GitHub, Mistral, Perplexity, Anthropic API). Calendario rinnovi reali: 24 giu Vercel $57,67 (scaduto), 2 lug iubenda €27,98, 3 lug Supabase $25 + GitHub $4, 4 lug Claude Max €180, 12 lug Vercel nuovo ciclo. Tutte sulla 9808 tranne GitHub → azione founder: pagare Vercel oggi e spostare Vercel + Supabase + iubenda + Claude sulla 6073 entro il 2 luglio, o falliscono a catena. Burn ricorrente reale ≈ CHF 305/mese (+ ~100 del Claude di Loris che paga lui). Nuovi: execution/stack-costi-pagamenti.md (vista umana) + in status.json cost_registry i nodi _card_map e _payment_calendar (SSoT strutturata, alimenta /costs e fa da seme al Pianeta Finanza).

Cosa 2 — avvio Pianeta Finanza (7°) per dogfooding interno. Decisione founder: accendere ora il Pianeta Finanza, usarlo internamente riempito con i nostri costi veri, aprirlo ai clienti ~agosto 2026. Scopo prodotto: ogni PMI tiene traccia dei costi aziendali + scadenzario "cosa pago e quando" + allarme carta-che-fallisce; moat = import automatico dalle fatture email (il lavoro fatto a mano in questa sessione). NON è cassa/POS né partita doppia. Modello dati (tabelle finance_cost_entries + finance_payment_methods, RLS per workspace), seme reale e handoff con prompt di kickoff in ops/pianeta-finanza-dogfooding-2026-06-24.md. Piano Finanza nel cantiere.json promosso 0% → 8% (building, dogfooding interno); canon 02-product.md § Finanza aggiornato. ⚠️ Il codice del pianeta si costruisce nel repo prodotto D:\Desktop\Multiverbe (oggi 0% codice): la vista interna provvisoria è la pagina /costs del BOS.

Owner: Gregorio (decisioni + codice). Loris (business owner Finanza/HR). Claude (stack + spec + BOS).

---

Chi: Gregorio ("fammi uno scontrino di tutto ciò che è stato speso… conferma tu stesso da browser TUTTO quanto… poi aggiorna bos e chiudi, io faccio solo i login") · Claude (ricognizione fatture Gmail + verifica live sui cruscotti via Chrome MCP, loggato dal founder).

Perché: il founder voleva la spesa reale, non le stime. Il cost_registry del BOS era fermo all'audit del 16 maggio e in alcuni punti sbagliato. Abbiamo controllato i pagamenti uno per uno, prima nelle email poi dentro i cruscotti veri (Vercel, Anthropic, Supabase, Mistral, Perplexity, iubenda, GitHub).

Numeri reali (verificati):

• Speso totale ≈ CHF 500 (il BOS diceva 246). Anthropic claude.ai €383,43 (Pro → Max 5x → Max 20x €180/mese dal 4 giu) · Anthropic API console $21,62 · Vercel pagato $52,98 · Supabase Pro $25 (pagato) · iubenda €27,98/mese (pagato) · Perplexity $10,81 · Mistral $10 · GitHub $4.
• Costo mensile reale ≈ CHF 300/mese (il BOS diceva 166), più ~CHF 100/mese del Claude di Loris (lo paga lui di tasca sua).
• Incassato CHF 0 (nessun cliente pagante).
• Credito prepagato ancora fermo ≈ CHF 25 (Perplexity $9,99, Mistral $10, Anthropic API $6,90, Vercel AI Gateway $5): pagato ma non consumato.

Drift del BOS corretti (in source/_meta/status.json cost_registry + capital_state, execution/spese-mensili.md, source/_meta/cantiere.json):

1. iubenda non è gratis: due piani attivi e pagati dal 3 giu — Essentials su multiverbe.com €5,99 + Advanced su multiverbe.app €21,99 = €27,98/mese. Il BOS lo dava gratis con un paywall futuro.
2. Claude: da CHF 102 a CHF 180/mese (Max 20x).
3. Supabase: da gratis a Pro $25 pagato.
4. GitHub: da 0 a $4 pagato (su carta Visa 6073).
5. Burn e speso totale: 166 → 300/mese; 246 → 500.

Crisi pagamento Vercel (P0): la fattura di giugno è $57,67 (non $20: $20 di Pro + ~$37 di uso on-demand), stato OVERDUE. La carta Mastercard 9808 è stata rifiutata 8 volte, prossimo tentativo 24 giu; i progetti erano già stati sospesi il 6 giu e riattivati a mano il 7. Scoperta chiave: due carte. La 9808 fallisce ed è usata da Vercel, iubenda e claude.ai; la Visa 6073 funziona ed è usata da GitHub, Mistral, Perplexity, Anthropic API. Azione founder: pagare i $57,67 e spostare Vercel + iubenda sulla 6073 prima del rinnovo del 2 luglio.

Altre scoperte dalla casella:

• 🟢 Google Business Profile API APPROVATA il 18 giu (case 7-0288000041625): il BOS la dà ancora "in review" → da considerare fatta. La scheda Google di Multiverbe ha però 0 visualizzazioni (Metaverbe 47).
• 🟡 Sicurezza: sull'account Stripe "Metaverbe" il 2FA è stato disattivato il 10 mag e creata una nuova chiave privata il 19 mag (combacia col setup di Stripe LIVE, ma un conto pagamenti col 2FA spento è un rischio → riattivarlo e verificare la chiave).
• Google Ads nella casella è dell'agenzia Metaverbe (€6,18, per giunta falliti sulla 9808), non di Multiverbe: quindi "ads Multiverbe = 0" resta corretto.

Owner: Gregorio (login + pagamenti). Claude (ricognizione + verifica + aggiornamento BOS). Memoria salvata: project_costi_reali_gmail_2026-06-23.md.

---

Chi: Gregorio (menu di prosecuzione: "Booking ancora più fine + verifica live + mi fermo + chip per il resto; aggiorna tutto e chiudi") · Claude (refine → review focalizzata → fix → merge).

Cosa (1 PR #422, born-green, squash d650536): l'etichetta dell'unità di capacità nell'editor servizi Booking (camere/tavoli/posti) ora deriva dal booking_model catturato all'accensione (planet_setups.config), corretta per qualsiasi settore (incl. "altro"), non solo quelli cablati sul sector_id. Helper puro capacityUnitForModel (testato) + lettura fail-soft del modello in BookingSettings (tabella gated/assente → fallback al settore, comportamento invariato). È il 2° consumatore reale del campo catturato (rinforza la REGOLA FERREA).

Review focalizzata (feature-dev:code-reviewer) → 1 finding important CONFERMATO e risolto: con if (u) return u il modello appointments (unità '') ricadeva sul settore → un gym che sceglie appuntamenti mostrava 'posti'. Fix: il modello catturato è autoritativo (return capacityUnitForModel(...) diretto); fallback al settore solo se il modello non è ancora catturato. Gate verdi born-green (build, 1548 test, lint 453<560, depcruise, knip). CI verde, squash-merge.

Verifica live (#4 del menu): il per-pianeta gate dipende SOLO da planet_setups (verificato: VITE_ONBOARDING_V2 gatekeepa solo il wizard di onboarding iniziale). Resta da fare una volta che il founder applica la migration: giro reale del gate Booking via Chrome MCP loggato (scelta → seed → widget con slot). Chip aperto per il prossimo pianeta v2 (Web/Content/Sales, seed provabile).

Owner: Gregorio (decisioni). Claude (codice + review + gate + merge + allineamento).

---

Chi: Gregorio (mandato ultracode: "Booking v2 deve essere TOP, perfetto per ogni settore; fai una ricerca online per affinare; qualità big-tech nei dettagli; completezza per la messa in produzione, poi merge e tutto il necessario per allinearci") · Claude (headless: grounding DB live → implementazione → review avversariale 5+6 assi → ricerca web CH → ship → merge → allinea).

Contesto: prosecuzione di #417 (setup progressivo v1 = sola "accensione" per-pianeta). v2 = ogni pianeta cattura 1 scelta reale che lo SEEDA davvero (zero dati finti). Primo pianeta: Booking.

Il buco reale (grounding DB live read-only): 0/10 workspace in prod hanno una riga booking_settings → opening_hours vuoto → getAvailableSlots genera ZERO slot → widget muto. Il trigger di onboarding semina i SERVIZI dal catalogo settoriale (sector_default_services), MAI gli orari. Questo è il tappo silenzioso che il seed v2 toglie.

Cosa (1 PR #420, born-green, squash-merge a CI verde dce424c):

1. Framework v2 riusabile: campo dichiarativo opzionale (field) sulla spec del pianeta (planet-setup.ts). Solo Booking ne ha uno; gli altri 5 restano v1 "solo accensione". Il gate (PlanetSetupGate) rende il campo come radio-group accessibile (native radio nascoste → tastiera completa, focus-ring, fieldset/legend), preselezionato dal settore, e passa config a onConfigure; markConfigured(planet, config) persiste in planet_setups.config. Guardia anti-drift (test): i value delle scelte = i BookingModel del seed.
2. Scelta Booking: "Cosa prenotano i tuoi clienti?" → appuntamenti/tavoli/camere/posti, preselezionata dal settore (suggestBookingModel).
3. Seed PER SETTORE (features/booking/lib/seed-defaults.ts, fail-soft + idempotente): resolveSeedProfile(settore, modello) = profilo di SETTORE quando il titolare conferma il modello suggerito dal suo settore, altrimenti profilo del MODELLO (override o settore sconosciuto). Profili con convenzioni CH reali (ricerca web 2026): parrucchiere/estetica Mar-Sab con lunedì chiuso e mai domenica (regola cantonale TI verificata); palestra fasce ampie + weekend; studio medico orari clinici con pausa pranzo; bar giornata lunga; immobiliari Lun-Ven + sabato mattina. Oltre agli orari semina buffer (5-10 min), preavviso disdetta (4-48h), finestra (30-365 gg) = best practice scheduling. Non distruttivo: orari solo se assenti/vuoti, regole scalari solo alla CREAZIONE della riga. + 1 servizio del modello solo se il workspace ne ha zero (settori non coperti dal trigger). La "chiusura del lunedì" si esprime omettendo il giorno dagli orari (booking_settings LIVE NON ha closed_days).

REGOLA FERREA rispettata: tutto ciò che si semina è LETTO dal motore. Test linchpin: gli orari del profilo danno slot>0 in getAvailableSlots; parrucchiere → ZERO slot lun/dom provato sul motore; gym → slot anche di domenica; rooms → percorso a notte. +47 test sui due file (full suite 1547 pass).

Metodo (ultracode): grounding DB live + dry-run rolled-back sullo schema reale (writes schema-valid) → implementazione → review avversariale (1° giro 5 lenti 0 finding sul v2 base; 2° giro 6 lenti dopo il refactor per-settore → 1 finding medium ux-copy CONFERMATO: la nota statica "orari e regole tipici del tuo settore" era falsa su override/settori-fallback (~15/21) → ammorbidita a "di partenza adatti a come lavori", onesta per ogni tenant) → fix → re-gate. Gate verdi born-green: build, 1547 test, lint 453<560, depcruise, knip.

Founder-gated (per testarlo dal vivo): applicare database/migrations/2026-06-23b_planet_setups.sql + VITE_ONBOARDING_V2=true su Vercel multiverbe-app + redeploy. Senza, il gate resta dormiente (fail-soft, comportamento identico a oggi). ⚠️ Blocker invariato: pagamento Vercel.

Owner: Gregorio (decisioni). Claude (codice + ricerca + review + gate + merge + allineamento). Stato onboarding progressivo: v2 attivo su Booking; gli altri 5 pianeti restano v1 ignite-only (candidati a v2 in PR separate dove esiste un seed provabile: Web→obiettivo sito/SiteBuilder, Content→cadenza/calendario, Sales→ICP; Marketing = Business-tier, planned).

---

Chi: Gregorio (mandato ultracode permanente, autonomia totale: "7ª constitution = HOTEL / B&B, gold-standard ≥ real-estate; fai tutto da solo — autora, gate locali, apri la PR e MERGIALA a CI verde, APPLICA tu la migration su prod via upsert+verifica MCP, aggiorna memoria + BOS; unica cosa che non puoi: pagare Vercel") · Claude (headless: ricerca multi-agente → authoring → review avversariale 6 assi → ship → apply DB → verifica).

Contesto: prosecuzione del moat siti multi-settore, da v152 (6 constitution LIVE). Hotel/B&B è il 3° modello "ospitalità" booking-led ma con specificità forti: prenotazione camere con tariffe per notte/stagione, multilingua turistico dominante (DE+EN pesano più che altrove — 63% ospiti svizzero-tedeschi), check-in/out, posizione che vende, recensioni driver #1. Una sola constitution serve l'albergo strutturato e il piccolo B&B familiare (tier-aware).

Cosa (1 PR #419, born-green, squash-merge a CI verde + apply DB prod):

1. Constitution hotel (gold-standard, la più ricca finora: 92KB JSON / 48kB col). schemaOrgType: Hotel (B&B → override BedAndBreakfast; LodgingBusiness per ibridi). conversionGoals: room_booking (KPI #1) · availability_check · phone_call. 15 pageRecipes IT/DE/FR/EN, 13 sezioni enriched (le 3 nuove rooms-showcase/availability-search/amenities), 4 moodSpecs, 4 A/B, 6 seasonal (eventi 2026 reali: JazzAscona/Moon&Stars/Locarno Film Festival 5-15 ago), 67 forbiddenPhrases (IT+DE+EN+FR · deny-list "alberghese").

   • Tipi estesi (additivi): SchemaOrgType += Hotel/BedAndBreakfast/LodgingBusiness · ConversionGoalType += room_booking/availability_check · SectionType += rooms-showcase/availability-search/amenities · PageType += camere/prenota/dintorni. Mood RIUSATI (luxury-glam/warm-italian/modern-minimal/human-approachable) → nessun edit design-tokens (pattern confermato 5×: gym/prof-svc/aesthetics/real-estate/hotel; tsc è l'oracolo).
   • schema.org a 3 nodi (validato web giugno 2026): LodgingBusiness + HotelRoom["HotelRoom","Product"] + Offer/UnitPriceSpecification (unitCode DAY per notte / IE per persona, CHF, businessFunction LeaseOut). Honest: NESSUN rich result lodging organico su Google; stelle su PROPRIE recensioni INELEGGIBILI in SERP (rischio manual action) → aggregateRating/FAQPage valgono per knowledge panel + citazione AI/GEO. Vacation Rental = solo Hotel Center (non puntarci).
   • CRO moat CH: Lex Booking (clausole di parità vietate in CH dal 1 dic 2022 → "prezzo migliore solo qui" è legale qui, rischioso altrove) + EU Digital Fairness Act (scarsità falsa vietata dal 19 giu 2026 → "X camere rimaste" solo se legato a inventario reale = hard gate). Best-rate guarantee in hero, flusso ≤4 step, perks>sconti (accanto al prezzo, non sconto pubblico che danneggia ranking OTA), foto ≥4/camera incl. bagno, recensioni volume>perfezione (4.6/800 > 4.9/200).
   • CH-Ticino corretto: IVA alloggio 3.8% (camera+colazione, estesa al 2036) / extra 8.1%; tassa di soggiorno (hotel 4-5★ CHF 4.50 p.p./notte, 1-3★ 4.20, B&B/appartamenti 2.00, campeggi/ostelli 3.10) → finanzia il Ticino Ticket (trasporti gratis ospiti = leva, non costo). Locale it→de→en→fr, MAI solo IT. TWINT+carte (turisti non usano TWINT). Trust signal reali (Hotelstars/HotellerieSuisse, Swisstainable I/II/III, Ticino Ticket partner, Design Hotels). Grigioni = inversione stagionale (inverno = alta sci).

2. 🟢 Applicata LIVE su prod. Upsert locale service-role (one-off cancellato, NON committato, con guard che rifiuta URL ≠ yqhixdqipojvgzfadufo) → verifica MCP: SELECT (jtype object, 48kB, 15 pages, has SC 3.3.8, no "Pietro", no EUR) + get_advisors security (3 INFO pre-esist.) + performance (163 INFO/2 WARN pre-esist., site_constitutions 0 hit) = 0 nuovi warning. 7 constitution ora active (aesthetics/gym/hair-salon/hotel/prof-services/real-estate/restaurant).

Metodo (ultracode): workflow ricerca parallela 5 agenti web (schema.org / CRO booking diretto vs OTA / a11y datepicker / mercato CH-Ticino / copy+benchmark, ~433k token) → authoring → workflow review avversariale 6 assi (sector-truth 96, type-contract 97, CRO 94, schema 93, copy 91, a11y 91 — datepicker bulletproof: APG combobox, celle non-disp. focalizzabili+motivo, SC 2.4.11 sticky-bar C43, 2.5.7/2.5.8/3.3.7; eccede l'86 di real-estate) → 10 rifiniture applicate (la più importante: la review ha trovato il gap WCAG 2.2 SC 3.3.8 Accessible Authentication → aggiunto guest-checkout/paste-password/no-CAPTCHA) → re-gate → merge → apply.

⚠️ 2 lezioni CI: (1) il batch gate locale (tsc/knip/depcruise/lint/test/build) NON include scripts/check-internal-leaks.mjs (gira nel job "Typecheck + build") → ha bloccato il primo CI su "Pietro" (nome persona riservato: blocklist Loris/Gregorio/Carla/Pietro/Sofia/Yuki) → girarlo SEMPRE in locale per constitution con example-copy; nomi inventati ok (Tognola/Marta/Emilio/Lucia). (2) il check "types/supabase.ts ↔ prod schema" fa flaky-fail su rate-limit del download Supabase CLI ("Failed to resolve latest Supabase CLI release: rate limit exceeded") → re-run del job (gh run rerun --job <id>), non è un drift reale.

Owner: Gregorio (decisioni/canon). Claude (codice + ricerca + review + gate + merge + apply DB + verifica). Stato Site Builder: 7/21 settori con constitution dedicata, tutti LIVE. Prossimi: studio-medico, bar (resta restaurant = F&B), macro vendita/creativi/eventi. ⚠️ Blocker invariato: pagamento Vercel (i siti pubblicati = *.multiverbe.app).

---

Chi: Gregorio (mandato ultracode, autonomia totale: "6ª constitution = agenzia immobiliare, gold-standard al livello di cura più alto; fai tutto da solo — autora, gate, apri la PR e mergiala a CI verde, APPLICA tu le migration su prod via MCP; applica anche le 3 migration constitution rimaste in sospeso così tutti i settori vanno LIVE insieme; aggiorna memoria + BOS") · Claude (sessione headless: ricerca multi-agente → authoring → review avversariale → ship → apply DB → verifica).

Contesto: prosecuzione del "gap #1 del moat" (siti multi-settore), da v150 (5 constitution). L'immobiliare era nei top-7 pre-MVP ed era stato ESCLUSO da #414 perché è un terzo modello, il più complesso: annunci-led a doppio pubblico (chi vende/affitta + chi compra/cerca), non booking-led né lead-led puro.

Cosa (1 PR #418, born-green, squash-merge a CI verde + apply DB prod):

1. Constitution real-estate (gold-standard, la più ricca di tutte: 82.7KB JSON). schemaOrgType: RealEstateAgent. Hero a schede ("Valuta la tua casa" default + "Cerca casa", mai due CTA gemelle). conversionGoals: valutazione venditore (KPI #1 → mandato) · richiesta info annuncio · prenota visita. 16 pageRecipes IT/DE/FR/EN, 14 sezioni enriched (le 3 nuove valuation-cta/property-search/property-listings con a11y WCAG 2.2 piena: combobox APG, slider multi-thumb + alternativa al drag SC 2.5.7, mappa SUPPLEMENTARE, contratto errori form), 5 A/B, 52 forbiddenPhrases, schema.org a due nodi (RealEstateListing pagina + Accommodation Apartment/House/SingleFamilyResidence + Offer Sell/LeaseOut), pagina immobile-dettaglio.

   • Tipi estesi (additivi): SchemaOrgType += RealEstateAgent · ConversionGoalType += valuation_request/property_inquiry/viewing_booking · SectionType += property-listings/property-search/valuation-cta · PageType += immobili/immobile-dettaglio/vendi/cerca. Mood RIUSATI (luxury-glam/modern-minimal/human-approachable/authoritative-classic) → nessun edit design-tokens (riconferma il pattern v150: riusare mood = niente gotcha; tsc è l'oracolo).
   • CH-Ticino corretto (dominio validato sul web): X.5 locali (mai bilocale/vani), mandato di mediazione, atto pubblico/rogito + riservazione (NO compromesso/contratto preliminare/caparra confirmatoria italiani — in CH la vendita è valida solo per atto notarile, art. 216 CO), Registro Fondiario, CECE (no APE), SVIT Ticino/CATEF/LIIm (no USPI=romanda), Lex Koller (vietato il claim assoluto "permesso B/C UE non è straniero"), provvigione ~3% + IVA 8.1% a carico del venditore, CHF 1'250'000.-.

2. 🟢 TUTTE le constitution applicate LIVE su prod (sblocco dell'intero Site Builder). Scoperta verificando lo stato reale del DB: in prod solo restaurant era attivo; hair-salon era uno STUB da 46 byte INATTIVO (la generazione sito per i parrucchieri era rotta, non in fallback), e gym/professional-services/aesthetics non erano mai state applicate (il "founder-gated" di v149/v150 non era mai stato eseguito). Applicate tutte e 5 (hair-salon + gym + prof-services + aesthetics + real-estate) → 6 constitution ora active & servite dal worker. Verifica MCP: SELECT (json_type=object, 26-40KB, 13-17 pageRecipes ciascuna) + get_advisors security+performance = 0 nuovi warning (site_constitutions mai citato). Lezione: "founder-gated" ≠ "fatto" — verifica sempre lo stato reale del DB prima di assumere.

Metodo (ultracode): workflow ricerca parallela (4 agenti web: schema.org / CRO portali CH / a11y WCAG 2.2 / mercato Ticino) → authoring → workflow review avversariale 6 assi (a11y 86 = unico sotto-bar → fixato; altri ≥90; type-parity 96, la più ricca delle 6) con verifica di ogni finding → fix pass (P0+P1+P2) → re-gate. ⚠️ Apply: il JSON 54-85KB non è trascrivibile byte-exact in una call MCP (un escape sbagliato rompe l'SQL) → upsert locale service-role dai sorgenti TS (idempotente, stesso path del worker) + verifica via MCP. Riusabile per i prossimi seed grossi.

Owner: Gregorio (decisioni/canon). Claude (codice + ricerca + review + gate + merge + apply DB + verifica). Stato Site Builder: 6/21 settori con constitution dedicata, tutti LIVE. Prossimi: studio-medico, hotel/bnb/bar, macro vendita/creativi/eventi. ⚠️ Blocker invariato: pagamento Vercel (i siti pubblicati = *.multiverbe.app).

---

Chi: Gregorio (mandato ultracode: "l'onboarding migliore in assoluto, esperienza perfetta; un solo onboarding configura il proprio Multiverbe AI + impostazioni importanti, poi il resto si configura pianeta per pianeta in base a cosa serve → un solo onboarding per ogni abbonamento"; "rifinisci, production ready, commit, push, aggiorna il BOS, metti tutto online senza lasciarcelo indietro") · Claude (sessione headless: understand → design → implement → review avversariale → ship; gate verdi, born-green, squash-merge #417 a CI verde).

Cosa (1 PR, #417, gate verdi + review avversariale 0 critical, squash-merge → auto-deploy multiverbe.app):

1. Setup progressivo per-pianeta (nuovo). Un solo onboarding accende il Multiverbe AI + gli essenziali per tutti i tier; poi ogni Pianeta si accende da sé alla prima apertura, solo quelli che servono.

   • Tabella planet_setups (migration 2026-06-23b, GATED): stato accensione per (workspace, pianeta), RLS canonica owner-write/member-read + trigger completed_at. Fail-soft: finché non applicata, dormiente (l'app si comporta come prima).
   • PlanetSetupGate nel PlanetPanel: scheda cosmica "Accendi il Pianeta X", mostrata solo al titolare (owner) e nel suo tier (i pianeti locked restano gestiti dall'UpgradeModal esistente). Riusa useTierPlanets / planet_registry.tiers_available. La config profonda resta nei satelliti del pianeta.
   • Reframe Step4Tour: rimossi i nomi MAIND (OPERA/CONNESSIONI/FINANZA), "Sole AI" → "Multiverbe" (l'AI verso l'utente), pill viola ed em-dash; chiusura sul modello progressivo + "inizia dal Pianeta X" (da default_for_macros).

2. Hardening fallback settore. Bug reale: keyword-table copriva 27/28 settori (mancava immobiliari → real-estate cadeva su agenzia-comunicazione o sul default consulente). Matching word-boundary (uccide falsi positivi bar⊄"barbiere", pr⊄"impresa/prodotto"). computeActiveModules estratto in lib pura. Guardie anti-drift: copertura 28 settori + integrità catalogo (seed non vuoti) + cross-tier (catalogo TS == whitelist API). +76 test.

Metodo (ultracode): workflow di mappatura (6 lettori) + grounding DB dal vivo (planet_registry.tiers_available = SSoT tier; workspace_planet_autonomy = pattern per-pianeta da specchiare; RLS canonico verificato) + workflow di review avversariale (4 lenti, verifica di ogni finding). 9 finding (0 critical): risolto il check ruolo owner (HIGH, gate solo al titolare), console.warn dev-only nell'hook, motion-safe sullo spinner; lasciati i low (convenzione enum / backlog UX); focus-outline cyan pre-esistente → task separato.

Azioni founder (gated): (1) applicare database/migrations/2026-06-23b_planet_setups.sql → accende il setup progressivo; (2) VITE_ONBOARDING_V2=true su Vercel multiverbe-app + redeploy → accende l'onboarding V2 (già production-ready). ⚠️ Blocker invariato: pagamento Vercel.

Owner: Gregorio (apply migration + flag) · Claude (codice + review + gate + merge). BOS allineato: questa entry + cantiere.json (onb-v2 90%, nuovo nodo onb-progressive, _meta.updated_by).

---

Chi: Gregorio (mandato "altissima qualità", 3ª constitution palestra; poi menu → Servizi pro; poi menu → 2+1 = estetica ora + handoff immobiliari) · Claude (sessione headless, gate verdi, ogni PR born-green e squash-merge a CI verde).

Contesto: prosecuzione del "gap #1 del moat" (siti multi-settore). Si partiva da 2 constitution (restaurant + hair-salon #409). Ne sono state aggiunte 3 nella stessa sessione → copertura a 5 settori dedicati (più i 4 sector_id servizi-pro serviti da una sola constitution).

Cosa (3 PR, gate-verdi, squash-merge; ogni merge = auto-deploy multiverbe.app):

1. PR #412 · Palestra / gym (ExerciseGym, booking-led). Conversione primaria = prova gratuita (trial_signup). 14 pageRecipes IT/DE/FR/EN, 4 mood nuovi (bold-energetic/performance-strength/premium-wellness/community-driven), 12 sezioni enriched, copy anti-slop (no "rimettiti in forma"/"il tuo benessere"). Esteso types.ts (SchemaOrgType += ExerciseGym/SportsActivityLocation/HealthClub · MoodTag +4 · ConversionGoalType += trial_signup/class_booking/membership_signup · SectionType += free-trial/class-schedule/membership-pricing · PageType += corsi/abbonamenti/trainer/prova-gratuita). Gotcha risolto alla radice: i 4 nuovi mood obbligavano a estendere 2 Record<mood> esaustivi in design-tokens.ts (radius+shadow); grep non li vede (indexed-access type), tsc sì → l'oracolo è il typecheck, non il grep. Migration 2026-06-23a.

2. PR #414 · Studi professionali (ProfessionalService, lead-led — primo settore non-booking). Una sola constitution copre 4 sector_id del macro servizi-pro: studio-legale, commercialista, studio-tecnico (architetto/ingegnere), consulente. Immobiliari escluso (modello annunci/RealEstateAgent → constitution dedicata, top-7 pre-MVP). Primaria = richiesta consulenza (lead_form), secondaria = prima call (calendly_book). 13 pageRecipes, 4 mood riusati (authoritative-classic/modern-tech/human-approachable/modern-minimal per gli studi tecnici), 12 sezioni enriched. Divieto esplicito di promesse di esito (etica forense) in forbiddenPhrases. Contratto: serviva solo SectionType += case-studies | process-steps (lo scaffolding del primo autore copriva già schema.org/goal/page dei pro) → niente nuovo mood = niente edit design-tokens. Migration 2026-06-23b.

3. PR #416 · Centro estetico (BeautySalon, booking-led, parente di hair-salon). Primaria = prenotazione; before/after + galleria come driver di fiducia; gdpr-photo-consent (foto pelle = dato sensibile). 13 pageRecipes, 4 mood riusati (pastel-soft/natural-organic/luxury-glam + premium-wellness riusato da gym) → ZERO modifiche al contratto, zero edit design-tokens. Il pattern al suo costo minimo. Migration 2026-06-23c. Wiring estetica → 'aesthetics'.

Pattern consolidato (ora provato 3×): estendi le union in types.ts SOLO se servono (riusa tipi/mood esistenti dove puoi → eviti il gotcha design-tokens) → constitutions/<id>.ts (mirror hair-salon) → seed-<id>-constitution.ts → migration idempotente ON CONFLICT (round-trip JSON validato) → 1 riga in SECTOR_TO_CONSTITUTION (keyed sul sector_id vero; una constitution può servire più sector_id). Nessun registry TS: la constitution raggiunge prod via seed DB, il worker la carica per constitution_id.

Gate (ogni PR, born-green prima del push): tsc base+api · vitest 1452 · knip 0 · depcruise 0 · lint 455/560 (0 nuovi) · vite build. Modalità risparmio CI rispettata (pochi commit coesi, 1 PR per unità, squash-merge; PR stacked via cherry-pick su master aggiornato).

Azioni founder residue (GATED): applicare le 3 migration su DB prod (yqhixdqipojvgzfadufo): 2026-06-23a_seed_gym + 2026-06-23b_seed_professional_services + 2026-06-23c_seed_aesthetics. Senza apply i template esistono nel codice ma il worker non li serve (i settori ricadono sul fallback 'restaurant'). + review contenuto constitution (forbiddenPhrases/aiPrompts) come per le precedenti. ⚠️ Blocker esistenziale invariato: pagamento Vercel.

Prossimo naturale: immobiliari (top-7 pre-MVP, modello NUOVO — RealEstateAgent + annunci/valutazioni/visite, conversione = richiesta valutazione / prenota visita): merita una sessione fresca (handoff generato). Poi studio-medico, hotel/bnb, macro vendita/creativi/eventi.

Owner: Gregorio (apply 3 migration + pagamento Vercel) · Claude (codice + gate + merge).

BOS allineato: questa entry. Memoria durevole: project_gym_constitution_2026_06_23 (pattern + gotcha + flusso git stacked-PR). status.json/cantiere non toccati da Claude: il Pianeta Web guadagna copertura settori (site-builder 2→5 constitution) ma il ricalcolo weighted della maturità è del founder.

Chiusura: founder menu "2+1" (estetica fatta + handoff immobiliari).

---

Chi: Gregorio ("perché sul PC vedo una pessima copia 2D e non il sistema solare 3D? eliminala, funzioni sempre, e se non funziona per mancanza di connessione deve decadere in modo intelligente, non un'immagine neanche cliccabile" → "procedi in totale autonomia" → menu 1+2 = aggiorna BOS + sistema la texture) · Claude (sessione headless · diagnosi LIVE via Chrome MCP sul browser del founder · gate verdi · merge a CI verde).

Sintomo: sul PC del founder la scena centrale mostrava una copia 2D statica e non cliccabile invece del sistema solare 3D.

Causa vera (diagnosticata live, NON indovinata): multiverbe-logo.glb ha extensionsRequired: [KHR_draco_mesh_compression, EXT_texture_webp] → mesh DRACO-compressa. drei carica il decoder DRACO dal CDN gstatic, che la CSP del progetto (script-src/connect-src senza www.gstatic.com) blocca → Failed to fetch → il GLB non si decodifica → useGLTF resta in Suspense per sempre → fallback 2D permanente. = il "non funziona per mancanza di connessione" del founder: il 3D dipendeva da un fetch esterno. (WebGL2 sul PC del founder — GTX 1060 — funziona: NON era capacità.)

Cosa (3 PR, gate-verdi, squash-merge; ogni merge = auto-deploy multiverbe.app):

1. PR #410 · self-host del decoder DRACO (LA cura). Vendor di draco_wasm_wrapper.js + draco_decoder.wasm (variante gltf three.js) in public/draco/; i 5 call-site useGLTF(URL, true, …) → useGLTF(URL, '/draco/', …) (Pianeta ×2, Sole ×2, NavbarNucleus3D ×1) — drei usa la stringa come decoder path locale. Same-origin → coperto da default-src 'self'. Zero modifiche alla CSP, niente CDN esterno → il 3D si carica sempre, anche offline. .gitattributes *.wasm/*.glb binary (un byte alterato = decoder corrotto = 3D muto) + .semgrepignore per il decoder vendored (FP emscripten).

2. PR #404 · fallback robusto (rete di sicurezza). Il fallback non è più un'immagine morta: (a) recupero context-lost (remount Canvas via key, retry ×3 invece del latch permanente); (b) hasWebGL2() rilascia il contesto di test (loseContext); (c) fallback SVG interattivo (6 pianeti cliccabili "Tocca un pianeta per aprirlo" + "Riprova il 3D"); (d) reduced-motion non congela più la scena (il founder ce l'ha ON → vedeva un overview lontano e immobile = percepito 2D; ora ambientMotion = !freeze, orbite + Sole vivi, solo l'intro dolly gatato). Geometria/posizioni pianeti invariate.

3. PR #411 · CSP connect-src blob: (rifinitura texture). Residuo dopo #410: la texture WebP embedded (EXT_texture_webp) dava Couldn't load texture blob perché three la carica via fetch(blob:) e connect-src non aveva blob:. Aggiunto blob: (1 token, già in img-src/worker-src). Rischio basso: blob: = dati in-memory della pagina, non una destinazione di rete. Era già non-fatale (shader procedurali), ma elimina il rumore in console.

Verificato LIVE (Chrome MCP sul browser del founder, GTX 1060): drei fetcha il decoder da /draco/ (200, same-origin, zero gstatic); nuovo bundle live; screenshot = sistema solare 3D che renderizza (Sole monolite + 6 pianeti-occhio coi loro colori + starfield); fetch(blob:) ora OK; console pulita dei 3 errori DRACO/texture (resta solo un errore di un'estensione del browser, non nostro).

Azioni founder residue: nessuna code-side. Sul proprio PC: hard reload Ctrl+Shift+R per scaricare il bundle vecchio dalla cache. ⚠️ Blocker esistenziale invariato: pagamento Vercel 23/6.

Owner: Claude (codice + diagnosi + gate + merge) · Gregorio (hard reload + pagamento Vercel).

BOS allineato: questa entry (decisions-log). status.json/cantiere NON toccati: bug-fix di rendering, non cambia le percentuali di maturità.

Chiusura: founder menu "1+2". Memoria durevole: project_3d_fallback_robustness_2026_06_22 (con lezioni di metodo: Chrome MCP apre una finestra separata spesso in background → rAF throttled = artefatti; un mio stress-test di 32 contesti WebGL ha sfrattato il contesto reale).

---

Chi: Gregorio (mandato: "collega il più possibile, qualità estrema"; menu → scelta task 1+2) · Claude (sessione headless, gate verdi, merge a CI verde).

Cosa (2 PR, gate-verdi, squash-merge; ogni merge = auto-deploy multiverbe.app):

1. PR #407 · Churn band-based nel Sole. L'insight crm_churn del Sole era un mero conteggio di dormienti; ora è band-aware sulle bande RFM-T per-contatto (che #402 calcolava ma l'insight ignorava). Lo step compute-churn-scores in analyze-planet-data ora gira prima degli insight e produce un ChurnSummary (puro, PII-free: solo conteggi + max LTV aggregato) riusato sia dal rule-based sia dall'agente (payload crm con churn_detail). Priorità ai clienti di valore a rischio (LTV alto + banda medio/alto), poi banda 'alto', poi fallback al conteggio solo se le bande mancano. Se le bande dicono "nessuno a rischio" non si inventa urgenza. Una lettura + un calcolo, riusati per tabella crm_contact_scores E insight. 24 test. Nessun nuovo cron.

2. PR #409 · 2ª constitution Site Builder: parrucchiere (hair-salon). Era il "gap #1 del moat": una sola constitution (restaurant). Aggiunta hair-salon.ts gold-standard (~1550 righe, SectorConstitutionEnriched: HairSalon schema, 4 mood pastel-soft/urban-edgy/natural-organic/luxury-glam, 13 pageRecipes, 11 sezioni enriched, CRO CH-Ticino, before/after+portfolio come driver di fiducia, copy anti-cliché humanizzato) + seed script + migration 2026-06-22d (idempotente, GATED). Wiring root-fix: la mappa settore→constitution era keyed per sector_id ma alimentata col business_type grossolano → non matchava mai, tutto cadeva sul fallback 'restaurant'. Ora useWorkspace espone sectorId e il wizard mappa sul settore vero (parrucchiere→hair-salon). Rimosso un hardcoded restaurant-specifico mostrato per ogni settore. La constitution è type-checkata dal tsc base (la cartella constitutions/ NON è esclusa dai gate, solo ai-pipeline).

Stato prod verificato (read-only): la migration churn crm_contact_scores NON è applicata (ultima applicata = 2026-06-22c_lead_candidates_industry, la Sales #408) → il churn band-based gira in fail-soft (conteggio) finché il founder non applica 2026-06-22c_crm_contact_scores.sql. ⚠️ Collisione di naming: nel repo 2026-06-22c è usato sia dal file churn (crm_contact_scores, non applicato) sia, in prod, dalla Sales (lead_candidates_industry, applicata). Cosmetica (Supabase versiona per timestamp), ma da sapere quando si applica la churn.

Azioni founder residue (gated): (1) applicare migration churn 2026-06-22c_crm_contact_scores.sql → accende il churn band-based reale + il badge rischio; (2) applicare migration hair-salon 2026-06-22d_seed_hair_salon_constitution.sql → mette la constitution in DB (altrimenti il parrucchiere ricade su 'restaurant'); (3) QStash (QSTASH_*) per e2e reale generazione sito; (4) review contenuto constitution (forbiddenPhrases/aiPrompts, come per restaurant). ⚠️ Blocker esistenziale invariato: pagamento Vercel 23/6.

Prossimo naturale: altre constitution (gym, professional-services/studio, estetica, hotel) col medesimo pattern (file + seed + migration + 1 riga di mapping); oppure wiring Sentry (init pre-consenso → consent-gate come PostHog).

Owner: Gregorio (apply migration + pagamento Vercel) · Claude (codice + gate + merge).

BOS allineato: questa entry + cantiere.json (p-crm churn band-aware, site-builder 2ª constitution, _meta.updated_by).

Chiusura: founder "qui chiudiamo, aggiorna bos e tutto quanto". Lasciato un chip pronto-da-cliccare per la 3ª constitution (palestra/gym, stesso pattern file+seed+migration+1 riga di mapping; estende le union schema.org/mood in types.ts). Memoria durevole: project_churn_band_hairsalon_2026_06_22.

---

Chi: Gregorio ("miglioriamo ciò che si può e aggiorniamo completamente il BOS su tutto così possiamo chiudere") · Claude (sessione headless).

Cosa: a valle delle 3 PR della Fase 1 (v144 #395+#400, v146 #403), una quarta PR di rifinitura rende i lead da discovery più completi, poi BOS allineato e sessione chiusa. Sempre zero-key e sovrano.

• PR #408 (rifinitura) MERGED — born-green: (1) industria leggibile: mappa inversa categoria OSM → etichetta IT (es. amenity=restaurant → "Ristorazione"), salvata su lead_candidates.industry al discovery e portata sul lead all'approvazione (prima era nulla); (2) enrichment email dal sito: endpoint /api/sales/enrich (manager, rate-limit) che fa SSRF-fetch di homepage + pagine "contatti" ed estrae un'email plausibile (scarta noreply/piattaforme/nomi-file, preferisce il dominio); l'approvazione lo chiama best-effort (fail-soft) e fa dedup per email (collega a un lead esistente invece di duplicarlo). +12 test puri. Migration additiva 2026-06-22c applicata a prod + types rigenerati nello stesso commit. Advisor 0 nuovi.

Riepilogo Fase 1 lead-gen (4 PR, tutte MERGED in autonomia, gate-verdi): #395 ICP (cervello) · #400 discovery sovrana (OSM/Overpass + fit-score + candidati) · #403 mappa (MapLibre + PMTiles self-host) · #408 rifinitura (industria + email). Il pianeta Sales ora ha il "trova i tuoi clienti" end-to-end fino al lead arricchito; p-sales nel cantiere passa a 90%.

Azioni founder rimaste (provisioning, non codice): (1) GEOAPIFY_API_KEY su Vercel multiverbe-app — key verificata live (HTTP 200) — + restringere/ruotare (era in chat) · (2) upload .pmtiles CH/EU + VITE_PMTILES_BASEMAP_URL + redeploy (recipe docs/pmtiles-basemap.md) per accendere la mappa stradale · (3) caselle SMTP per l'invio outreach reale · (4) Fase 2 premium $ = Dealfront/Cognism nella waterfall.

⚠️ Blocker esistenziale invariato: Vercel pagamento 23/6 — al prossimo rifiuto prod + BOS + landing si spengono.

BOS allineato: questa entry + cantiere.json (p-sales 90% con la nota lead-gen, _meta.updated_by).

Owner: Gregorio (provisioning + pagamento Vercel) · Claude (codice + gate + merge).

---

Chi: Gregorio (mandato autonomia "il resto del lead-gen, zero-key"; menu prosecuzione → "costruisco il frontend mappa ora (dormant)"; fornita la key Geoapify) · Claude (sessione headless).

Cosa: chiusa la Fase 1 del motore lead-gen del pianeta Sales con la terza e ultima PR. Le tre tappe sono tutte MERGED, born-green, in autonomia: #395 ICP → #400 discovery → #403 mappa (vedi anche v144).

• PR2 #403 (la mappa) — tab "Mappa" nel satellite Lead: i candidati discovery su mappa reale. MapLibre GL 5.24 + pmtiles 4.4 + @protomaps/basemaps 5.7 (stack open, validato sul web giugno 2026). Pin colorati per affinità + cerchio del raggio + slider che scrive il reach (default_radius_km) nell'ICP + click pin → approva (→lead) / scarta. Componente lazy → il bundle mappa (302KB gz) resta in un chunk separato, fuori dal main. Helper geometrici puri testati (+7). NIENTE Mapbox, NIENTE MapTiler.
• Basemap = PMTiles Protomaps SELF-HOSTED, dormant: finché VITE_PMTILES_BASEMAP_URL è assente la mappa gira in fallback (sfondo + pin + raggio, banner), mai un basemap di terze parti. Il file .pmtiles lo carica il founder — recipe leggera in frontend/multiverbe-app/docs/pmtiles-basemap.md: pmtiles extract dal build globale Protomaps (ranged, poche centinaia di MB, NON planetiler multi-GB) → upload Supabase Storage → env → redeploy. Glyphs/sprite = asset pubblici Protomaps (zero-key, env-override).

Geoapify (discovery hedge, PR1b): il founder ha fornito la API key → verificata LIVE (HTTP 200, ristoranti reali di Lugano, query-shape dell'adapter corretta). Va messa in Vercel env GEOAPIFY_API_KEY (multiverbe-app) — azione founder. ⚠️ Essendo passata in chat va ristretta (referrer/IP) o ruotata. Default discovery resta Overpass; SALES_PLACES_PROVIDER=geoapify per renderlo default. La key NON è (e non va) committata.

Azioni founder rimaste (provisioning, non codice): (1) GEOAPIFY_API_KEY su Vercel + restrict/rotate · (2) upload .pmtiles CH/EU + VITE_PMTILES_BASEMAP_URL + redeploy · (3) Fase 2 premium $ = Dealfront/Cognism.

⚠️ Blocker esistenziale invariato: Vercel pagamento 23/6 — al prossimo rifiuto prod + BOS + landing si spengono.

Owner: Gregorio (provisioning + pagamento Vercel) · Claude (codice + gate + merge).

---

Chi: Gregorio (mandato sessione autonoma: "iniziare a collegare il piu possibile a Multiverbe, con estrema qualita"; barra: funzionante + testato + zero dati finti + advisor 0 errori) · Claude (sessione headless, gate verdi, merge a CI verde).

Cosa (5 PR, tutte gate-verdi, merge squash; ogni merge = auto-deploy multiverbe.app):

1. PR #398 · PostHog session replay + mascheramento PII opzione A. Acceso il replay (consent-gated Klaro, host EU). Mascheramento MIRATO (scelta founder, opzione A "replay ricche, PII nascosta"): attributo data-ph-mask a livello di contenitore su OGNI superficie che mostra PII dei clienti del titolare (CRM directory/messaggi/timeline/feedback/customer-value, Sales lead/deal/coda-chiamate/outreach/command-palette/import, Booking, dashboard rate, notifiche in-app · 18 file, 34 tag). maskAllInputs copre gli input. VITE_POSTHOG_KEY gia su Production -> telemetria + replay ATTIVI.
2. PR #401 · Site Builder Stage 4 immagini AI sovrane. I 4 client immagine erano stub ("not yet implemented"). Cablati al gateway sovrano Imagen 4 su Vertex EU (lo stesso del Content Studio), via dependency injection (OrchestratorConfig.images), perche l'orchestrator vive in src/ e dep-cruiser vieta src/->api/ (leak segreti/PII). Upload storage workspace-scoped + provenance reale in site_assets.ai_meta; fail-closed (503) se Vertex non provisionato. Rimossi i 4 stub (incl. il path bfl.ai vietato dal registry). e2e completo gated da QStash.
3. PR #402 · Predittore churn CRM integrato. Il calcolatore RFM-T (puro+testato) era su branch non integrato; ora cablato: migration 2026-06-22c (vista crm_contact_signals_v + tabella crm_contact_scores, RLS workspace-scoped, GATED = founder applica in prod) + batch giornaliero (step in analyze-planet-data delle 06:00, NESSUN nuovo cron, fail-soft finche la migration non c'e) + badge "Rischio medio/alto" nella directory contatti. SQL della vista validato read-only su prod prima del commit.
4. PR #399 · Bug naming SERPER. Il codice cercava SERPER_API_KEY, il founder ha SERPER_KEY -> ricerca web trend scollegata in silenzio. Fix: SERPER_API_KEY canonico + alias SERPER_KEY, degrado pulito gia presente, test di regressione, .env.example documentato.

Env sovrane confermate (Vercel CLI, Production): Vertex EU (GCP_VERTEX_PROJECT/LOCATION, GCP_SA_CLIENT_EMAIL/PRIVATE_KEY), VOYAGE_API_KEY, OAUTH_TOKEN_ENCRYPTION_KEY + OAUTH_STATE_SECRET, GOOGLE_*_ENABLED -> motore AI sovrano provisionato, memoria pgvector piena, connettore Google pronto (resta solo "Login con Google" in-app). Cantiere allineato: be-sovereign 88%, bm-gbp 85% (connettore env-completo), p-crm churn integrato, be-sitegen Stage 4 reale, data-pgvector gia live.

Azioni founder residue (gated, lasciate in checklist): pagamento Vercel (carta 9808, tentativo 23/6 = blocca tutto); applicare migration churn 2026-06-22c; signup QStash/Upstash (QSTASH_*, avvia la pipeline sito); app X (X_CLIENT_ID/SECRET); progetto Sentry (SENTRY_DSN/VITE_SENTRY_DSN); rinominare progetto PostHog 207416 in "Multiverbe"; entita Sagl (sblocca Stripe + Meta); smoke test reale Vertex generate-text/generate-image dietro auth.

Lezione: con PC che si sospende sopravvive solo cio che e su Git -> completamento sincrono, push+PR+merge per ogni unita; gate verdi in locale PRIMA del push (cost-mode). Il cluster site-builder+ai-pipeline e escluso dai gate tsc (debito noto): verificato ZERO nuovi errori via baseline-diff sul cluster.

---

Chi: Gregorio (mandato esplicito "procedi in autonomia col merge + il resto del lead-gen, percorso zero-key; i servizi a chiave li provisiono dopo, in una sessione online") · Claude (sessione headless big-tech).

Cosa: chiuse e mergiate le prime due tappe del motore lead-generation del pianeta Sales — la feature "trova i TUOI clienti" per ogni PMI. Tutto zero-key e sovrano (nessun provider US, nessuna chiave): i servizi premium restano dormant/Fase 2, li accende il founder.

• PR1a #395 (il cervello) — tabella sales_icp_profiles: il Sole deduce dal settore il Profilo Cliente Ideale (industrie/dimensioni/ruoli/segnali/esclusioni) + reach per-offerta (locale es. installazione stufe vs spedibile es. pellet in tutta la CH). UI "Profilo & ricerca" nel satellite Lead.
• PR1b #400 (la discovery) — endpoint /api/sales/discover (solo manager): geocoda la sede (Nominatim, zero-key) → mappa le industrie ICP su tag OpenStreetMap (dizionario curato ~45 categorie PMI + fallback LLM sovrano EU) → cerca aziende reali nel raggio via Overpass/OSM → fit-score firmografico (industrie/keyword/esclusioni/distanza, assi separati) → coda lead_candidates (propose→approve) → approva = diventa lead (gestione esistente #369). Bottone "Trova clienti" nel tab Profilo & ricerca.

Provider astratto (PlacesProvider): Overpass default (zero-key). Geoapify dormant dietro GEOAPIFY_API_KEY (503 se assente, mai downgrade silenzioso).

Qualità/sicurezza: safe-fetch SSRF-hardened condiviso su OGNI fetch esterna; selettori OSM validati = anti-injection Overpass QL; RLS workspace-scoped + planet-gate sales RESTRICTIVE su entrambe le tabelle; nessuna PII verso US (OSM pubblico; unico hop LLM = gateway sovrano EU, ledger content_generations). Born-green: gate locali tutti verdi (test +34, typecheck/build/lint/esm/leaks/sole-parity/depcruise/knip), CI verde, advisor security 0 nuovi finding. Migration additive applicate a prod + types rigenerati nello stesso commit.

Resta (azione founder · sessione online):

• PR2 mappa (MapLibre GL): la basemap = PMTiles Protomaps SELF-HOSTED (build CH/EU da OSM Geofabrik via planetiler/tippecanoe → upload su Supabase Storage → servita via HTTP range requests, zero-key zero-costo-per-tile). È un asset multi-GB che si genera/carica in una sessione online dedicata (la sessione headless non scarica/builda/carica GB né può verificare la mappa live); poi il frontend MapLibre (pin candidati + selettore raggio/area che scrive l'ICP reach) si accende dormant-gated sull'URL PMTiles. NIENTE Mapbox (cleanup #363), NIENTE MapTiler (preferiamo self-host).
• Geoapify (hedge qualità POI): account su geoapify.com (free 3k crediti/g) → GEOAPIFY_API_KEY su Vercel multiverbe-app → l'adapter si attiva da solo (SALES_PLACES_PROVIDER=geoapify).
• Fase 2 (premium $, founder-gated): Dealfront/Cognism (registri d'impresa EU) nella waterfall enrichment.

⚠️ Blocker esistenziale invariato: Vercel pagamento 23/6 — al prossimo rifiuto prod + BOS + landing si spengono (tolleranza in scadenza). Pagare/aggiornare il metodo è azione founder ineludibile.

Owner: Gregorio · Claude.

---

Chi: Gregorio ("A mascheramento mirato; rinomina PostHog in Multiverbe; procediamo ora che Google è pronto; apri X, QStash, Sentry; cabla Vertex; risolvi bug; testa cosa è a posto e risolvi; sessione piena → genera un chip che lavori su tutto, aggiorna tutto") · Claude.

1 · Inventario env reale (via Vercel CLI, ciò che l'audit non poteva leggere). La realtà è molto migliore delle deduzioni: GIÀ IMPOSTATE su Production = Vertex AI EU (GCP_*), Voyage (memoria), client OAuth Google, Stripe completo (9 price + webhook + secret), Inngest, Upstash, push VAPID, CRON_SECRET, SMTP_ENCRYPTION_KEY, Perplexity, Mistral, Brevo, Replicate, PostHog. Le voci del cantiere "Vertex 85%" e "memoria 92%" erano GIUSTE, non stale.

2 · Sblocco autonomo del connettore Google. Mancava davvero solo OAUTH_TOKEN_ENCRYPTION_KEY (+ OAUTH_STATE_SECRET): la chiave madre che cifra i token, senza la quale nessun connettore salva la connessione (anche col client Google già presente). Generate casuali (mai mostrate) e impostate su Production; più GOOGLE_SEARCH_CONSOLE_ENABLED=true e GOOGLE_BUSINESS_PROFILE_ENABLED=true. → Google ora è completo (client + cifratura + flag + GBP API approvata 18/6 + Search Console verificata): serve solo un redeploy dell'app + "Login con Google" in-app.

3 · Buchi env reali rimasti (pochi). Da founder (account esterni): X_CLIENT_ID/SECRET, QSTASH_TOKEN + signing (immagini sito), SENTRY_DSN, MOONSHOT_API_KEY. Da verificare il valore on/off: VITE_ONBOARDING_V2, GROWTH_STRATEGIST_ENABLED. Bug codice: SERPER_KEY vs SERPER_API_KEY (ricerca web scollegata per un nome sbagliato).

4 · Scelta replay = A (mascheramento mirato). La PR Multiverbe#398 va completata marcando i componenti con PII (data-ph-mask) e poi mergiata. Host EU, consent-gated.

5 · Chip generato per il resto (task_e048e0d4, cwd repo codice): completa+mergia #398 con mascheramento mirato; cabla le immagini Site Builder al gateway Vertex EU (già attivo); integra churn (branch claude/crm-churn-score); verifica Vertex e2e; fix bug SERPER; testa pianeta per pianeta e risolve; redeploy app (attiva Google + PostHog); aggiorna BOS. Founder-gated lasciati in checklist (X/QStash/Sentry/rinomina PostHog/Login Google/pagamento Vercel 23/Sagl).

Owner: Gregorio (account esterni + pagamento Vercel) · Loris (Sagl) · Claude/chip (codice + test + redeploy + BOS).

---

Chi: Gregorio ("riconcilia ciò che è standby, poi chiudiamo") · Claude.

Cosa: riconciliato l'unico standby rimasto. La sessione del 21/06 aveva scritto un'entry decisions-log dettagliata per #390 (Fase 3b) ma NON l'aveva pushata (divergenza 3-vie → finita sul branch locale backup/bos-local-divergence-2026-06-22). #390 è poi stato MERGED oggi (ec5e992, vedi v138). Qui salvo il razionale di design — che NON era su origin — prima di ritirare il branch.

#390 · bozza social content.draft_post via LLM per-famiglia (in TUTTE le lingue, IT inclusa: la bozza è un post da rivedere, non una comunicazione 1-a-1 → la varietà vale ovunque, rischio basso perché non parte a nessuno; competitor_gap resta curata in IT). 3 nodi di design (decisi da ingegnere, non escalati): (1) theme-less — placeholderRules per-AZIONE (deriva hasTheme dal req): la bozza senza tema vuole solo {businessName}, il competitor-gap {businessName}+{theme}; una sola code-path (DRY). (2) lead-in stagionale #364 — il gancio «perché ora» resta curato e si prepende server-side al corpo LLM (resolveContentCopy opts.leadIn); pass-through #357 intatto (body stabile preview↔commit → niente 409). (3) usageMetric content.draft_post null→'ai_generations' (campo senza consumatori a valle, il ledger 'copy' conta già lì, fail-open → nessun doppio gate). + umlaut-nudge de (mantieni ä/ö/ü, solo ß→ss). Routing invariato (Mistral FR EU + Gemini EU).

⚠️ Nota cross-cutting ancora valida (recuperata dall'entry): l'alias mistral-medium-latest in provider-registry.ts è condiviso con l'outreach LIVE e gli alias -latest Mistral possono rompersi → pinnarlo a versione esplicita (mistral-medium-3-5) è un task separato da tenere in vista.

Branch backup/bos-local-divergence-2026-06-22 RITIRATO: conteneva questa entry (ora salvata qui) + un primo-draft della security-entry già superato da v134/v138/v140. Divergenza risolta, zero standby residuo.

Owner: Gregorio · Claude.

---

Chi: Gregorio ("procediamo con posthog … e comprendiamo come procedere con TUTTO ciò che manca da agganciare … qualsiasi cosa serva a multiverbe per performare al meglio"; "scegli con attenzione tutti i servizi utili"; "collegati tu via browser e procedi in autonomia con estrema qualità") · Claude (browser PostHog + audit a 4 agenti).

1 · PostHog impostato (via browser, in autonomia). Account/progetto EU del founder (project 207416, regione EU/Francoforte). Prodotti selezionati con criterio: 10 su 11 — Product Analytics, Web Analytics, Session Replay, AI observability, Data Warehouse, Feature Flags, Experiments, Error Tracking, Surveys, Logs; ESCLUSO Workflows (automatizza le comunicazioni agli utenti = mestiere del Sole, non lo deleghiamo). Presa la project key (phc_…) e impostata su Vercel multiverbe-app (Production): VITE_POSTHOG_KEY, VITE_POSTHOG_HOST (eu.i.posthog.com), VITE_POSTHOG_PROJECT_ID=207416. L'SDK #387 si accende al prossimo deploy (analytics + web + autocapture, consent-gated Klaro). Session replay acceso nel codice in PR Multiverbe#398 (consent-gated, input mascherati, EU), NON mergiata: in attesa decisione founder sul mascheramento del TESTO con PII dei clienti (opzione A mirata vs B maschera-tutto). PostHog sostituisce Clarity come da v135; il progetto PostHog è ancora "Default project" (da rinominare "Multiverbe").

2 · MAPPA CABLAGGIO completa. Audit a 4 agenti (env/config + feature dormienti + infra) → ops/mappa-cablaggio-2026-06-22.md: ~54 voci, quasi tutte "già costruite e testate, spente in attesa di un interruttore" (env su Vercel). TOP 5 accendi-prima: (1) pagare Vercel (scade 23/6), (2) OAUTH_TOKEN_ENCRYPTION_KEY + OAUTH_STATE_SECRET = chiave madre di TUTTI i connettori OAuth (30s), (3) VITE_ONBOARDING_V2=true (onboarding 18 settori, TTFV 8-10min→3min), (4) VITE_POSTHOG_KEY (fatto), (5) verificare CRON_SECRET (i 4 cron, incl. il pubblicatore che fallisce in silenzio = collo del 30/6). 3 dipendenze trasversali: entità Sagl (Loris, sblocca Stripe-fatturazione + verifica Meta→WhatsApp/IG), OAUTH_TOKEN_ENCRYPTION_KEY (Gregorio, 30s), Vertex AI EU (service account GCP, ~1h, motore di tutta la generazione AI: oggi 503).

3 · Bug trovati di passaggio (da correggere). (a) Naming env web search: il .env del founder ha SERPER_KEY ma il codice cerca SERPER_API_KEY → ricerca web di fatto scollegata. (b) Incongruenze BOS↔realtà da ri-verificare in prod: Vertex "live 85%" (forse non provisionato), pgvector/Voyage "live 92%" vs "wire 40%". (c) Quality Check §9 overdue ~2 settimane. Primo passo operativo consigliato: aprire il pannello Env di Vercel e fare l'inventario reale (metà mappa si chiarisce in 10 min).

Owner: Gregorio (env Vercel + scelta A/B replay) · Loris (Sagl) · Claude (wiring adapter Google/Site-Builder/churn + correzione bug SERPER).

---

Chi: Gregorio ("procedi con l'attività suggerita, poi chiudiamo") · Claude (inline, gate verdi).

Cosa: completata la pulizia finale aperta dal v138. Scoperto che 2 dei 3 GHSA rimasti in auditConfig.ignoreGhsas NON erano esbuild ma soppressioni stale già chiuse alla radice da #394:

• GHSA-4w7w-66w2-5vf9 = vite CVE-2026-39365 (moderate, dev-server .map) → patchato in vite 6.4.2, siamo su 6.4.3.
• GHSA-5xrq-8626-4rwp = vitest (critical, UI server file-read Windows) → patchato in 3.2.6, ci siamo. → Rimossi in PR #397 (security(deps), MERGED). pnpm audit --audit-level=moderate resta exit 0 (prova che sono chiusi, non nascosti).

esbuild RESTA soppresso (GHSA-gv7w-rqvm-qjhr, build-time): testato dal vivo l'override esbuild@0.28.1 (il patch) → vite build fallisce (vite 6.4.3 e 7 pinano esbuild ^0.25.0; errore transpile destructuring). Override resta 0.25.0. Sbloccabile solo con una vite che accetti esbuild ≥0.28 (vite 8 / rolldown-vite, major a parte; rischio build-time basso, non urgente).

Stato finale security: auditConfig.ignoreGhsas = 1 sola entry (esbuild). .trivyignore non esiste. security-audit (npm/pnpm audit + Trivy) verde su master, verificata con run manuale (npm-audit + Trivy success). Cambio #397 = solo package.json (−2 righe), lockfile invariato.

Totale arco (v134→v140): 5 PR (#392 security · #390 sblocco Fase 3b · #394 vite6+vitest3 · #396 sentry10 · #397 cleanup). Da "audit backlog che bloccava OGNI PR" a "1 sola soppressione documentata e testata".

Owner: Gregorio · Claude.

---

Chi: Gregorio (mandato: "assicurarmi che ciò che usiamo vada benissimo per l'Europa... più Multiverbe-indipendenti possibile... tabella di cosa serve, perché, fino a quanti free... poi online prendo le chiavi") · Claude (ricerca web giu 2026 + validazione + tabella).

Principio (coerente con "tutto internamente", cfr. v135 PostHog-only): si preferisce SEMPRE l'opzione open/self-hostable EU; i managed solo come upgrade opzionale; il premium B2B solo in Fase 2. Scoperta chiave: il percorso Fase 1 più indipendente NON richiede quasi nessuna chiave di terzi.

Servizi lead-gen + mappa (validati EU / qualità / indipendenza):

Servizio	A cosa serve	EU / sovranità	Indipendenza	Free fino a	Inizia a costare (≈ clienti)	Stato
MapLibre GL	rendering mappa (lib client)	open-source	TOTALE	sempre	mai	✅ default
Protomaps PMTiles (self-host)	tile vettoriali su Supabase Storage (range-request)	self-host EU	TOTALE	sempre (solo storage ~GB + banda)	mai per-tile	✅ default
Overpass (OSM)	discovery aziende per categoria+area	pubblico EU / self-host CH-OSM	ALTA	pubblico ~10k req/g/IP	self-host VPS €10-20/mo quando il pubblico limita (~50-100 clienti attivi/g)	✅ default zero-key
Nominatim (OSM)	geocoding sede→coord	pubblico EU / self-host	ALTA	1 req/s (1/workspace)	self-host se volume alto	✅ default zero-key
Geoapify	discovery+geocoding managed, ~400 cat., caching OK	EU (Germania)	MEDIA	3.000 crediti/g (~150-600 discovery/g)	$59/mo (API 10) oltre il free	⚙️ upgrade opz. (chiave)
MapTiler	tile managed (alt. a Protomaps)	EU (Svizzera/Zug)	BASSA	solo non-commerciale	a pagamento per uso commerciale	❌ scartato (Protomaps self-host vince)
Dealfront	discovery B2B premium da registri ufficiali EU	EU (DE/FI), GDPR-native	BASSA (dati ingeriti nel ns DB)	nessun free reale	contratto sales-led (~€€€/anno)	🔜 Fase 2
Cognism	contatti B2B verificati (telefono)	UK (adeguatezza EU), GDPR	BASSA	nessun free	contratto (~$15-25k/anno)	🔜 Fase 2

Core stack (già EU + nel guardrail spesa, INVARIATO): Supabase (Francoforte), Vercel, Anthropic (pseudonimizzato pre-US), Mistral FR, Vertex/Gemini EU, Brevo, Stripe, PostHog (EU). Nessun cambio.

Conseguenza operativa: Fase 1 (PR1b discovery + PR2 mappa) gira a ZERO chiavi di terzi (MapLibre + Protomaps self-host + Overpass + Nominatim) → costruibile in autonomia (chip task_d7bcecba). La sessione online col founder serve solo per le chiavi OPZIONALI: Geoapify (se Overpass pubblico limita) e, in Fase 2, i contratti premium Dealfront/Cognism. Le soglie sopra → ri-allineare nel guardrail spesa quando un servizio passa da free a pagamento.

Owner: Gregorio (decide gli upgrade + provisiona le chiavi online) · Claude (build sovrano zero-key).

---

Chi: Gregorio ("fai tutto in autonomia da cima a fondo con estrema qualità") · Claude (esecuzione autonoma; ogni gate locale verde + CI verde PRIMA di ogni merge).

Cosa: completata la catena aperta dal v134. Quattro PR mergiate in ordine, ognuna CI-verde:

1. #392 (security(deps)) — i 7 advisory transitive fixati alla radice + 3 soppressi documentati (vedi v134). MERGED.
2. #390 (Fase 3b copy LLM) — era parcheggiata SOLO sul backlog advisory; rebasata su master-con-#392, gate verdi (1344 test), MERGED. Il blocco "ogni PR ferma" è sciolto.
3. #394 (build(deps)) — vite 5→6.4.3 + vitest 2→3.2.6 (root + frontend + TUTTI i packages/*) + @vitejs/plugin-react 4.7. Chiude alla radice vite CVE-2026-53571 (HIGH) + GHSA-v6wh → rimossi .trivyignore e i 2 GHSA vite da ignoreGhsas. MERGED.
4. #396 (build(deps)) — @sentry/node + @sentry/react 8→10.59 (Sentry 10 = OpenTelemetry 2.x; Sentry 9 restava su OTel 1.x e NON bastava). Con tutto l'albero su OTel core 2.x l'override @opentelemetry/core@2→2.8.0 lo pinna alla versione patchata → chiude GHSA-8988 alla radice → rimosso da ignoreGhsas. MERGED.

Risultato: pnpm audit --audit-level=moderate = exit 0 con zero soppressioni moderate+. In auditConfig.ignoreGhsas restano SOLO i 3 GHSA esbuild build-time pre-esistenti (override esbuild@0.25.0). .trivyignore non esiste più. La security-audit (npm/pnpm audit + Trivy) è verde e onesta.

Verifica (per ogni PR · locale pnpm 10.28.2 + CI): build (tsc+vite 6) · frontend 1344 test · root test:coverage 1454 test · typecheck:api (API Sentry 10 compatibile) · lint · depcruise · knip · audit moderate · Trivy HIGH/CRITICAL — tutti verdi. Nessun breaking change ci tocca (config vite/vitest minimale; uso Sentry = init base + captureException/withScope + browserTracingIntegration).

Ultimo follow-up rimasto (ora SBLOCCATO da vite 6): i 3 GHSA esbuild — valutare il bump a esbuild ≥0.28.1 compatibile con vite 6 e togliere override+ignore. Era esplicitamente "bump vite poi togli l'ignore" → vite 6 è fatto. Vedi memory project_esbuild_advisory_ignore_2026_06_13.

Nota git BOS: l'entry Fase-3b/#390 di una sessione precedente resta non-pushata sul branch backup/bos-local-divergence-2026-06-22 (il CODICE #390 è però mergiato). Da riconciliare a parte (founder).

Owner: Gregorio · Claude.

---

Chi: Gregorio (mandato: trovare un modo per la review Meta senza la Sagl, che costa ed è a ~2 mesi; senza Meta il Pianeta Marketing è limitatissimo; "io il permesso non ce l'ho", Loris lavora da suo padre in PTEK nei Grigioni, "in CH per fatturare non per forza bisogna registrarsi"; ricerca approfondita) · Claude (ricerca web giu 2026). NB: ricerca operativa, NON consulenza legale: validare con commercialista/fiduciario.

1 · Il punto che sblocca tutto in un colpo. Meta NON chiede una verifica per ogni cliente. Per un SaaS multi-cliente si diventa Tech Provider = UNA verifica business + UNA App Review della nostra app; poi i clienti collegano il loro Instagram via "Business Login / Embedded Signup" SENZA review per-cliente. Quindi il collo è UNA verifica + UNA review, non N: risolverlo una volta accende Meta per tutti.

2 · Cosa accetta Meta. Serve un documento ufficiale di registrazione dell'azienda (nome legale + numero di registrazione/partita), eventualmente + bolletta. Documenti auto-prodotti o non ufficiali NON sono accettati. La ditta individuale è un tipo valido, ma serve comunque il documento ufficiale. → Una ditta individuale svizzera non iscritta (sotto CHF 100k, senza registro di commercio) non ha quel documento e rischia di non passare. Una ditta individuale iscritta volontariamente (si può anche sotto i 100k) avrebbe l'estratto ufficiale = accettabile.

3 · Il vincolo del permesso (Gregorio). In CH l'attività indipendente richiede un permesso che la consenta (UE/AELS → permesso B; Stati terzi → permesso C o coniuge di C/svizzero). Gregorio non ha ancora il permesso → ora non può esserne lui il titolare indipendente; Loris (già attivo in CH) è il candidato lato permesso. "Fatturare senza registrarsi" è vero per IVA/registro sotto CHF 100k (cognome pieno), ma resta obbligatoria l'iscrizione AVS come indipendente — e comunque NON basta a Meta.

4 · Scorciatoia consigliata: PTEK come veicolo-ponte. PTEK (azienda registrata del padre di Loris, Grigioni) è già un'entità svizzera ufficiale → passa la verifica Meta SUBITO. Si crea l'app Meta + verifica sotto il portfolio di PTEK ORA e si avvia l'App Review (che da sola dura 4-8 settimane), in parallelo alla Sagl; quando la Sagl esiste si migra app/portfolio. Si guadagnano ~2 mesi. Condizioni: accordo chiaro col padre/PTEK (diventa "business of record" temporaneo) + ok fiduciario.

5 · Vendere SUBITO senza Meta (in parallelo). Il Marketing non resta fermo: Multiverbe genera i contenuti (sovrano EU) e il cliente li pubblica dal suo Business Suite finché la nostra API non è approvata; intanto sono già pronti X/Twitter (#383), Google (GBP approvata + Search Console), sito/SEO ed email. La leva Meta auto-pubblica/insight si presenta come "in arrivo". Loris vende la visione completa con quasi tutto funzionante.

6 · Inventario collegamenti (2026-06-22). LIVE: Stripe · Email (Brevo + SMTP per-tenant + Mistral) · Clarity sulla landing (stopgap). PRONTI DA ACCENDERE (env/OAuth): Google one-consent (GA4+GSC+GBP, GBP API approvata 18/6) · X Free. DA COSTRUIRE (interno): PostHog (analytics + replay + heatmap, sostituisce Clarity). GATED da entità + App Review: Instagram/Meta · WhatsApp · LinkedIn · TikTok · YouTube · Pinterest.

7 · PostHog nello stack + costo scalabile. canon/05-stack.md aggiornato: PostHog Cloud EU = analytics + session replay + heatmap, free 5.000 registrazioni/mo + 1M eventi/mo, poi usage-based (~$0.005/registrazione) che cresce coi clienti (cappabile con sampling).

Owner: Gregorio + Loris (scelta veicolo PTEK vs ditta individuale vs Sagl, col fiduciario) · Claude (ricerca + build PostHog).

---

Chi: Gregorio (sessione dogfooding "connettere pezzo per pezzo" · mandato: metodo di qualità assoluta, costo no-object scalato nell'abbonamento, pan-EUROPEO, sector-intelligent, big-tech-grade) · Claude (ricerca web → architettura → build + gate + PR).

1 · Il buco chiuso a monte. public.leads aveva gestione completa (funnel/import/coda chiamate #369) ma ZERO discovery: i lead nascevano solo a mano/CSV. Serviva il motore che TROVA i clienti — feature di prodotto per ogni PMI, non solo per Multiverbe-azienda.

2 · Architettura best-in-class (validata sul web giu 2026 · non una fonte, una pipeline a 5 strati). (1) Settore→ICP (il Sole deduce industrie/dimensioni/ruoli/segnali dal settore); (2) reach per-offerta — local (raggio, es. installazione stufe) vs shippable (canton/national/eu/global, es. pellet in tutta la CH), deciso dal founder; (3) discovery pan-EU sovrana = Dealfront (registri d'impresa ufficiali EU, GDPR-native) in Fase 2; (4) waterfall enrichment (Dealfront→Cognism→agentico del Sole dal sito, 85-95% copertura contatto); (5) scoring ICP fit+intent (assi separati, decay, regole negative) = la garanzia "estrema qualità". Autonomia = guadagnata (propone→calibra ICP→riempie in continuo; outreach opt-in separato, si aggancia a send-outreach). Mappa = MapLibre (open-source, no Mapbox). Decisione founder: "sovrano ora + premium dopo" (provider-agnostico: Overpass/Geoapify + agentico in Fase 1; Dealfront/Cognism plug-in in Fase 2 quando firma i contratti).

3 · PR1a spedita (PR #395, gate-green, MERGE=founder). Tabella sales_icp_profiles (1:1 ws · RLS planet-gate sales RESTRICTIVE + member-read + manager-write · unique ws) · endpoint /api/sales/icp (GET · derive sovrano purpose longform→Gemini/Claude EU, niente PII, ledger content_generations · save upsert) · logica pura testata · UI "Profilo & ricerca" DENTRO il satellite Lead (SalesLeadsSurface, nessuna modifica al catalogo 3D). Migration additiva APPLICATA a prod + types rigenerati (no drift). Advisor security 0 nuovi. 9/9 gate locali verdi.

4 · Piano pezzo-per-pezzo. PR1b discovery Overpass + staging lead_candidates→leads · PR2 mappa MapLibre · Fase 2 provider premium EU.

Nota CI: il backlog audit (28 vuln) risulta CHIUSO da #392 (v134) → #395 dovrebbe avere CI pulita (confermare un run fresco di Security Audit su master).

Owner: Gregorio (merge + QA prod) · Claude (build).

---

Chi: Gregorio (browser connesso, mandato verbatim: "se con posthog tutto è fattibile a mano e non perde nulla contro clarity allora procediamo esclusivamente con lui anche perché penso sia free; prepariamoci già affinché da subito i clienti non debbano connettersi a un terzo come clarity da esterno e facciamo tutto internamente, questa è la nostra filosofia") · Claude (verifica + decisione + ricognizione browser).

1 · PostHog confermato → PostHog-only. Verificato (web, giu 2026): free tier 5.000 registrazioni sessione/mese + 1M eventi, session replay incluso nel free, hosting EU (Francoforte, AWS eu-central-1, stessa regione del nostro Supabase), heatmap incluse (click+scroll, un filo meno raffinate di Clarity ma presenti). PostHog è già in adozione per la telemetria di prodotto (#387). La condizione del founder è soddisfatta: andiamo PostHog-only. L'unico "meno" vs Clarity (heatmap meno sofisticate) è ampiamente compensato: session replay + heatmap + analytics di prodotto in un solo strumento europeo e nostro.

2 · Architettura "tutto interno" (filosofia founder). UN progetto PostHog EU di proprietà Multiverbe; l'SDK PostHog su app + landing + ogni sito-cliente (sites-runtime), consent-gated; ogni sessione taggata per workspace (PostHog "groups"); il cliente vede le SUE heatmap/registrazioni DENTRO Multiverbe (lette via API PostHog) e i segnali entrano nel Sole. I clienti non creano né collegano mai un account esterno. Non serve nemmeno provisioning per-cliente: un progetto unico + group-by-workspace.

3 · Clarity: stopgap, non si investe oltre. Clarity resta solo come tappabuchi sulla NOSTRA landing (già attivo, consent-gated, innocuo) finché PostHog session replay non è live, poi si rimuove. NON si collega il token Data Export Clarity (inutile dato il pivot). La guida connettori: per i clienti zero passi esterni con PostHog.

4 · Stato permessi (posta + browser, 2026-06-22). GOOGLE: Business Profile API APPROVATA (email 18 giu); Search Console multiverbe.com VERIFICATA; esiste una proprietà GA4 (G-RXQXD7FGGE) ma VUOTA (nessun tag installato, e con PostHog la nostra analytics non passa più da GA4); il connettore Google in app (che legge i dati Google dei CLIENTI) resta dormiente, serve un client OAuth + env per attivarlo. INSTAGRAM/META: nel Business Suite esiste Multiverbe (Pagina FB + profilo Instagram, 0 follower, appena creati) ma NON risulta un'app sviluppatore con permessi Instagram approvati; i messaggi "Meta Business Support" nella posta sono notifiche aziendali/onboarding, non approvazioni. I permessi Instagram NON sono concessi: richiedono app Meta + verifica business + App Review (settimane), gated dall'entità. Non ora.

5 · Prossimi passi. (a) creare il progetto PostHog EU + VITE_POSTHOG_KEY su Vercel; (b) accendere session replay + heatmap nell'SDK (già presente, #387) + group=workspace, consent-gated su tutte le superfici; (c) costruire il visore in-app (heatmap/registrazioni del cliente, lette da PostHog) + alimentare il Sole; (d) guida connettori in-app (per i clienti Clarity sparisce); (e) separato: connettere il connettore Google (OAuth client + env), utile per leggere i dati Google dei clienti.

Owner: Gregorio (account PostHog + entità per IG) · Claude (SDK replay + group + visore in-app + key su Vercel).

---

Chi: Gregorio (dal menu: "rendiamo la security-audit verde davvero", non solo i 3 HIGH del task) · Claude (triage→fix radice→soppressioni documentate→gate→PR).

Cosa: la CI security-audit (job npm/pnpm audit + Trivy), rossa su master dal 2026-06-15, torna verde. Estende v128 (ignore esbuild documentato) e il re-baseline dogfooding: il "backlog advisory che bloccava OGNI PR" è chiuso. Il triage ha mostrato che i 3 HIGH del task (undici, protobufjs, nodemailer) erano solo la punta: il DB advisory live aveva pubblicato nel frattempo un set più ampio sulle transitive del frontend (vite, dompurify, tar, js-yaml, @opentelemetry/core). Approccio da charter: fix alla radice dove esiste una patch compatibile, soppressione documentata solo per ciò che è dev-server-only o senza patch senza un major upgrade.

Fix alla radice (override pnpm in package.json root + bump della dep diretta):

• undici 6.24.0→6.27.0 (CVE-2026-12151) · protobufjs→7.6.4 (CVE-2026-48712) · nodemailer ^8→^9.0.1 (GHSA-p6gq-j5cr-w38f) · dompurify→^3.4.11 (via posthog-js, XSS/config) · js-yaml→^4.2.0 · tar→^7.5.16 · @opentelemetry/core@2→2.8.0 (patcha i path 2.x inngest/posthog).
• nodemailer 8→9: l'unico breaking (validazione TLS sui fetch di contenuti remoti) non tocca il nostro invio SMTP (auth user/pass, niente attachment/proxy, mai l'opzione raw dell'advisory).

Soppressioni documentate (pnpm.auditConfig.ignoreGhsas + nuovo file .trivyignore per gli HIGH, perché Trivy NON legge l'auditConfig di pnpm → vanno tenuti allineati):

• vite CVE-2026-53571 (HIGH) + GHSA-v6wh (moderate): riguardano SOLO il dev-server di Vite, mai eseguito in prod (serviamo dist/ statico). Patch solo in vite 6.4.3 (major) + vitest 3.
• @opentelemetry/core GHSA-8988 via @sentry/node: Sentry 8 gira su OpenTelemetry 1.x e l'advisory non ha patch 1.x; i path 2.x sono già patchati dall'override sopra. Residuo → Sentry 8→9 (major).

Scoperta utile: la security-audit NON è un required check sul branch master (lo è solo "Typecheck + build") → tecnicamente non bloccava il merge, ma operativamente la gatiamo. Inoltre il comando CI pnpm audit --audit-level=moderate (senza --prod, contro DB live) è destinato a ridiventare rosso col tempo (nuove advisory anche su dev-deps): da valutare in futuro un --prod/soglia ripensata. Conferma la richiesta del v128 (abilitare Dependabot/Renovate per i bump automatici).

Verifica locale (pnpm 10.28.2): pnpm audit --audit-level=moderate = exit 0, --audit-level=high --prod = exit 0; build (tsc+vite), 1335 test, typecheck:api, lint, depcruise, knip tutti verdi. CI PR #392: npm/pnpm audit, Trivy, Semgrep, Typecheck+build, commitlint, gitleaks, TruffleHog PASS.

Cosa sblocca: con la security-audit verde riparte il merge delle PR gatate dal backlog advisory — in primis #390 (Fase 3b copy LLM), ancora parcheggiata su questo blocco.

Follow-up tracciati (chiudono alla radice i 2 residui soppressi): upgrade major vite 6 + vitest 3 · upgrade major Sentry 8→9.

Stato: PR #392 CI-verde, MERGE = founder. Nessuna migration, nessun cron, nessuna env nuova.

Owner: Gregorio · Claude.

---

Chi: Gregorio (ha creato il progetto Clarity xazmjo2s89, GTM + Analytics collegati, "procedi tu con vercel"; mandato: deve valere per TUTTI i siti dei clienti, centralizzare il più possibile, creare una miniguida per le azioni che l'app non può fare da sola) · Claude (attivazione + verifica + guida, in autonomia).

1 · Landing attiva. Impostata NEXT_PUBLIC_CLARITY_PROJECT_ID=xazmjo2s89 su Vercel (project multiverbe-landing, Production) via CLI, poi redeploy git. Verificato live: il Project ID è inlined nel bundle (/_next/static/chunks/00dgvjmcg2j2o.js) e multiverbe.com risponde. Clarity si carica solo dopo il consenso statistiche (loader ClarityAnalytics, GDPR/nDSG). Aggiunto un guard anti doppia-iniezione: se lo snippet Clarity è già presente (per esempio caricato da Google Tag Manager) il loader non aggiunge un secondo script, conferma solo il consenso.

2 · Vale per TUTTI i siti-cliente (confermato nel codice). La sites-runtime è già pronta: app/[subdomain]/layout.tsx inietta <ClarityScript projectId=… /> (consent-gated, idempotente) quando il sito ha sites.clarity_project_id, letto da lib/data/fetch-page.ts. Quindi ogni sito generato con Multiverbe traccia in Clarity con il progetto del cliente nel momento in cui il titolare lo collega in app. Il "vale per tutti" è architetturale, non solo per noi.

3 · Scelta GTM: Clarity gestito da CODICE Multiverbe, non da GTM. Motivo principale: i siti dei clienti non hanno il nostro GTM (usano l'iniezione diretta della sites-runtime), quindi il codice diretto è l'unico modo uniforme per tutti e tiene il controllo dentro Multiverbe. Il GTM (GTM-NJ72HWMX) resta solo per i tag Google (GA4/Ads) sulla nostra landing. Azione founder: togliere o non pubblicare il tag Clarity dentro GTM, per evitare il doppio caricamento (il guard ci protegge comunque, ma la via pulita è una sola fonte).

4 · Loop dati nel Sole (residuo founder). La raccolta sul sito è attiva; per portare i dati DENTRO Multiverbe (cruscotto + memoria del Sole) serve collegare il token Data Export in app (Impostazioni → Microsoft Clarity): generare il token in Clarity e incollarlo. Pre-attivazione compliance: aggiungere Microsoft Clarity alla privacy policy + /subprocessors della landing.

5 · Miniguida creata. ops/guida-attivazione-connettori.md (linguaggio semplice, leggibile anche da Loris): è la fonte ufficiale dei testi che mostreremo in-app accanto a ogni connettore. Spiega il principio ("quasi tutto in un clic, Clarity è l'unica eccezione perché non si crea il progetto da fuori") e i passi Clarity. Prossimo passo (app): mostrare questi testi dentro la card di ogni connettore (faciliter dall'app, come da mandato founder).

6 · Direzione centralizzazione (founder). Ridurre a zero le azioni esterne. Idea registrata: sostituire Clarity con una raccolta dati propria (nostro tracciamento di mappe di calore e sessioni), così nessun account esterno e tutti i dati nascono dentro Multiverbe. Da valutare post-gate.

Owner: Gregorio (token Clarity + connessione in app + pulizia tag GTM) · Claude (landing attiva + guida + verifica auto-iniezione, fatto).

---

Chi: Gregorio ("aiutami a collegare clarity" → "procedi in completa autonomia con tutte le autorizzazioni") · Claude (lavoro di codice autonomo; i passi sull'account esterno restano del founder).

Contesto: Microsoft Clarity è il connettore "mappe di calore + registrazioni di sessione" del Pianeta Web, già nel codice ma spento. Per il dogfooding lo colleghiamo misurando la landing multiverbe.com (traffico reale, scelta founder "parti dalla landing").

1 · Scoperta che semplifica: nessuna env nuova lato app. Letto il codice del connettore (api/_lib/clarity.ts): isClarityConfigured() controlla SOLO OAUTH_TOKEN_ENCRYPTION_KEY, che è già in produzione (la usano tutti i connettori OAuth). Quindi l'endpoint POST /api/connectors/clarity/connect è già pronto: valida il token con una chiamata reale alla Data Export API prima di salvare (fail-closed), cifra il token in oauth_connections (provider microsoft_clarity) e propaga il projectId pubblico su sites.clarity_project_id. La card di collegamento è in Impostazioni → Microsoft Clarity (campi Project ID + API Token).

2 · Fatto in autonomia: landing resa Clarity-ready (repo Multiverbe-Landing). Nuovo componente ClarityAnalytics.tsx (consent-gated + env-driven + autonomo): carica lo snippet Clarity SOLO se (a) è impostata l'env pubblica NEXT_PUBLIC_CLARITY_PROJECT_ID e (b) c'è il consenso statistiche (localStorage multiverbe-consent-v1=granted, scritto dal ConsentBanner). Disaccoppiato dal banner di proposito (rileva il consenso da solo: mount-check + evento storage + controllo leggero), così funziona su qualsiasi versione del layout senza toccare il banner. Montato nel layout di main. Build di produzione verde, mergiato su main (commit 66d917a), deploy Vercel READY, multiverbe.com 200. Inerte di default: finché non si imposta l'env, non carica nulla (zero rischio, nessun tracking pre-consenso, GDPR/revFADP).

3 · Limite reale: i passi sull'account Clarity sono del founder. Nessun browser collegato (list_connected_browsers vuoto), quindi non ho potuto creare il progetto Clarity né generare il token al posto tuo (richiede login Microsoft su clarity.microsoft.com). Restano 4 passi founder: (a) creare il progetto Clarity → Project ID; (b) generare un token Data Export (JWT) in Clarity; (c) impostare NEXT_PUBLIC_CLARITY_PROJECT_ID su Vercel (project multiverbe-landing) + redeploy (NEXT_PUBLIC è inlined a build-time); (d) incollare Project ID + token in app (Impostazioni → Microsoft Clarity) per gli insight nel cruscotto + memoria del Sole. Tempistica: collegare il token DOPO che il progetto ha raccolto qualche sessione (la prova del token al connect fallisce su progetto vuoto).

4 · Pre-attivazione compliance: prima di impostare l'env in produzione, aggiungere Microsoft Clarity alla privacy policy + alla pagina /subprocessors della landing (skill multiverbe-ch-compliance). Clarity = nuovo sub-processor (statistiche/registrazioni).

Nota branch: il redesign coming-soon è su feat/sovereignty-claim-cs (STANDBY, non su main). Ho messo Clarity su main (produzione) senza toccare il branch redesign. Quando promuovi il redesign a main, va ri-aggiunto il mount <ClarityAnalytics /> al suo layout (una riga) — oppure lo faccio io in quel momento.

Owner: Gregorio (account Clarity + env + connessione in app) · Claude (codice landing, fatto).

---