MultiverbeBOS

Sole v2 — pianeti dinamici, tassonomia artisti, chat a card (2026-06-04)

Record di sessione (continuazione post #144). Due decisioni di prodotto confermate dal founder e poi eseguite in PR #174 (3 commit atomici, base master). Scritto come file dedicato perché execution/decisions-log.md era in scrittura da un'altra sessione in parallelo: integrare lì il rimando quando libero.

Decisioni di prodotto (confermate dal founder)

DEC-1 · Modello pianeti = due assi (accesso = tier, salienza = settore)

L'accesso ai pianeti resta deciso dal piano (canon F-2 del 2026-05-26 intatto: leva di upgrade, scena 3D, modale di upgrade invariati). Il settore decide la salienza, cioè quali pianeti il Sole mette in primo piano e lavora davvero.

  • Un produttore musicale su Pro ha il Booking sbloccato, ma è dormiente: il Sole concentra Web, Content, CRM e Sales e non assilla sugli slot vuoti.
  • Un ristorante su Starter lavora le prenotazioni come area centrale.

Questo scioglie il conflitto tra il brief (2026-06-03: "pianeti per tier E settore") e il canon F-2 ("per piano, non per settore"): il settore entra come rilevanza, non come gating. Il pricing non cambia, perché dare un pianeta extra a un settore romperebbe la leva commerciale.

SSoT del resolver: frontend/multiverbe-app/api/_lib/workspace-planets.ts (resolveWorkspacePlanets({ tier, sectorId, macroId, activeModules })).

DEC-2 · Tassonomia "Creativi & Artisti"

Scorporata la macro creativa da eventi e agenzie. Togliere il taglio "fotografo/eventi" come unico contenitore creativo.

  • Nuova macro creativi (8 settori): designer, illustratore, copywriter, fotografo*, studio-video*, produttore-musicale, musicista, studio-registrazione (* re-home da eventi).
  • eventi diventa "Agenzie & Eventi" (wedding-planner, agenzia-comunicazione, web-agency).
  • Da 5 a 6 macro, da 22 a 28 settori.

Verificato prima della migrazione: zero workspace reali sui settori creativi/eventi (in uso solo studio-legale/ristorante/parrucchiere, tutti di test). Rischio dati nullo.

Esecuzione (PR #174)

Task Cosa File chiave
T1 Pianeti dinamici: resolver + identità che nomina le aree attive + analyze-planet-data senza "hai 4 pianeti" fisso (set = unlocked(tier) ∩ pianeti-con-metriche) api/_lib/workspace-planets.ts, api/_lib/sole-identity.ts, api/_inngest/functions/analyze-planet-data.ts, src/types/planets.ts
T2 Tassonomia: migration prod + fallback TS + deduzione AI + keyword matcher migration 2026-06-04a, src/data/sectors-fallback.ts, api/ai/sector-deduction.ts, src/lib/sector-detection.ts, src/components/onboarding/SetupWizardV2.tsx
T3 Chat a card: sole-ask su buildSoleIdentity + suggerimenti a card (2 opzioni o 1 affondo) + SoleChat in HomePage api/ai/sole-ask.ts, src/hooks/useSoleAsk.ts, src/pages/home/SoleChat.tsx, src/pages/home/HomePage.tsx
T4 Proattività bounded: 1 proposta/turno, maxTokens stretti api/ai/sole-ask.ts (analyze e sole-crm erano già capati)

Migrazioni prod applicate via MCP: 2026-06-04a_creativi_artisti_taxonomy (tassonomia), 2026-06-04b_planet_registry_tier_align (riallinea planet_registry.tiers_available stale a F-2).

Acceptance

  • Zero conteggi/elenchi pianeti hardcoded: analyze-planet-data ha set dinamico; identità elenca le aree attive dal set sbloccato; rule-based gated per tier. ✅
  • Starter-ristorante e freelance-musicista hanno set diversi (salient): test + smoke verdi. ✅
  • Un produttore musicale/designer si riconosce nell'onboarding; deduzione AI a 28 settori. ✅
  • Chat con card 2-opzioni o 1-affondo, tap → invio; bounded. ✅
  • Identità litmus "freelance musicale in Svezia" ancora verde (zero residui IT/CH/PMI). ✅

Note rispetto al brief

  • #144 era già MERGED: il rebase T0 non serviva (verificato gh pr view 144 = MERGED).
  • planet_registry.tiers_available era stale (seed pre-F-2) ma non letto da nessun codice per il gating (la SSoT è planets.ts). Riallineato comunque (fix-at-root).

Cosa resta da fare (follow-up · non bloccanti per il gate)

Emersi dalla review di produzione (PR #174):

  • Gating per status subscription, app-wide. getWorkspaceTier (resolver), useSubscription e tier-caps.ts leggono il tier senza filtrare status: una riga canceled che restasse in tabella manterrebbe l'accesso. Va unificato in un solo helper "tier effettivo" usato da tutti e tre, per non far divergere il Sole dalla UI. Oggi non urgente (pre-lancio, 1 sola subscription active). Documentato inline in workspace-planets.ts.
  • Foregrounding salient/dormant nella Home. Il resolver espone già salient/dormant, ma la Home (daily-brief) elenca i pianeti staticamente. Usare la salienza per ordinare e sfumare i pianeti dormienti per settore.

Dal backlog Sole-identity (T5 · non toccato in questa sessione):

  • Overlay maturità stellare (dwarf/subgiant/giant/supergiant/hypergiant): scala da lockare col founder + CHECK DB da migrare (CHIEDERE prima).
  • Eval LLM-judge sull'output reale (card proattive + insight): gated ANTHROPIC_API_KEY + ok spesa.
  • Catalogo i18n UNICO Node+edge (oggi la prosa localizzata è duplicata Node/Deno).
  • Igiene dati: 3 colonne locale → 1 canonica (workspaces.primary_language) + dedup nome/settore tra workspaces e entity_profile (ALTER → CHIEDERE).
  • Compliance: nome operatore → Anthropic documentato in privacy/DPA/sub-processor.
  • QA madrelingua de/fr su tutta la prosa nuova (riga "aree attive", nomi settori, seed).
  • Humanizer su tutta la copy fallback (sole-crm + analyze it/de/fr/en).
  • Consolidamento cervelli edge (ai-copilot-*) su routing canonico + entity_memory (post-gate).

Owner: Gregorio (decisioni) · Claude (esecuzione)