Files
clienthub/.planning/PROJECT.md
T
simone 3b1f49d059 docs(v2.0): finalize roadmap + requirements — phases 7-11 approved for planning
- Upgrade PROJECT.md: v2.0 Business Operations Suite (unified catalog, offers with phases, public quotes, CRM pipeline, auto-provisioning)
- Create REQUIREMENTS.md sections: CAT-U, OFFER-B, QUOTE, CRM, WIN requirements for phases 7-11
- Extend ROADMAP.md: 5-phase structure (7-11), 14-19 days total, risk/flag registry
- Archive v1.0 milestone (phases 1-6, complete)
- Switch STATE.md to v2.0, status=planning
- Create research documents: STACK.md, FEATURES_v2.0.md, ARCHITECTURE.md, PITFALLS.md, SUMMARY.md

Ready for: /gsd-plan-phase 7

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-06-11 06:01:59 +02:00

7.4 KiB
Raw Blame History

ClientHub — Gestione Clienti & Dashboard

What This Is

Suite operativa per un consulente di personal branding, live su hub.iamcavalli.net (Coolify/Hetzner): un'area admin (/admin/*) per gestire clienti, progetti, offerte e pagamenti, e una dashboard cliente via link segreto (/client/[token]) dove ogni cliente vede lo stato del suo progetto. Con la v2.0 si espande in suite completa: catalogo servizi unificato, builder offerte con fasi, preventivi pubblici multistep e CRM con pipeline lead.

Core Value

Il cliente apre il link e vede esattamente a che punto è il suo progetto, cosa deve ancora succedere e cosa ha già approvato — senza dover scrivere email per chiedere aggiornamenti.

Current Milestone: v2.0 Business Operations Suite

Goal: Trasformare ClientHub da portale clienti a suite operativa completa: catalogo servizi unificato + builder offerte con fasi, generazione preventivi pubblici, e CRM con pipeline lead che al "Vinto" crea automaticamente cliente e progetto nell'hub.

Target features:

  • Catalogo & Offerte — tabella services unificata (sostituisce service_catalog + offer_services); builder offerte con fasi e drag&drop dei servizi tra fasi; tag tipo offerta (Entry, Signature, Retainer, custom); tier indipendenti (es. Signature A/B/C)
  • Preventivi — pagina pubblica multistep HTML/CSS generata da cliente + offerte + prezzi scelti di volta in volta; obiettivo delivery entro 2 ore dalla call
  • CRM — pipeline lead (→ Vinto/Perso, preventivo prerequisito); reminder follow-up in dashboard; al "Vinto" auto-crea cliente + progetto con fasi copiate dall'offerta scelta (modificabili, visibili nella pagina pubblica cliente), importo accettato, 1-4 pagamenti configurabili caso per caso

Requirements

Validated

Shipped in v1.0 (Phases 16, in produzione su hub.iamcavalli.net):

  • ✓ Ogni cliente ha un URL segreto univoco, nessun login (token rotatable + slug opzionale) — Phase 1/4
  • ✓ Dashboard cliente: brand, brief, fasi/task con stato, progress, multi-progetto — Phase 1/4
  • ✓ Il cliente approva deliverable (approved_at immutabile) e lascia commenti — Phase 2
  • ✓ Il cliente vede solo il totale accettato, mai i prezzi dei singoli servizi — Phase 2/3
  • ✓ Stato pagamenti acconto/saldo visibile al cliente — Phase 1
  • ✓ Link a documenti esterni + storico note/decisioni — Phase 1/2
  • ✓ Area admin completa: clienti, progetti, fasi, task, pagamenti, documenti — Phase 2/4
  • ✓ Catalogo servizi + quote builder admin (quote_items mai esposti al cliente) — Phase 3
  • ✓ Sistema offerte: macro/micro/servizi, assegnazione a progetti, forecast 12 mesi — Phase 5
  • ✓ Offerte attive visibili nella dashboard cliente (solo public_name) — Phase 5
  • ✓ UX admin: sidebar + dashboard operativa con KPI e activity feed — Phase 6

Active

Catalogo & Offerte (priorità 1):

  • Catalogo servizi unificato (nome + prezzo unitario) usato da offerte e preventivi
  • Offerta = nome + tag tipo (Entry/Signature/Retainer/custom) + fasi ordinate
  • Ogni fase di un'offerta contiene servizi assegnati, spostabili via drag&drop tra fasi
  • Migrazione dati: consolidare service_catalog + offer_services senza perdita

Preventivi (priorità 2):

  • Generazione preventivo: cliente + 1-3 offerte + prezzi impostati di volta in volta
  • Pagina pubblica multistep (HTML/CSS) consultabile dal lead via link
  • Delivery del preventivo entro 2 ore dalla call (flusso assistito)

CRM (priorità 3):

  • Pipeline lead con stati fino a Vinto/Perso (preventivo inviato come prerequisito del Vinto)
  • Reminder follow-up in dashboard: ultima interazione, chi contattare oggi
  • Al "Vinto": auto-creazione cliente + progetto con fasi copiate dall'offerta scelta, importo accettato, 1-4 pagamenti scelti caso per caso

Out of Scope

  • Fatturazione e invio fatture — la gestione contabile resta fuori, solo stato pagamenti
  • App mobile nativa — solo web responsive
  • Multi-utente con team — solo tu come admin per ora
  • Prezzi singoli visibili al cliente — vede solo il totale accettato
  • Email OTP per accesso cliente — design pronto ma deferito a batch successivo su richiesta utente
  • File hosting — documenti solo come URL esterni (v1 constraint, ancora valido)

Context

  • Produzione: hub.iamcavalli.net su Coolify (Hetzner), Postgres self-hosted, deploy via webhook Gitea
  • Stack: Next.js 16 App Router, Drizzle ORM, Auth.js v4 (admin), token middleware (clienti), Tailwind v4, shadcn/ui
  • Tutto sotto la stessa app: /admin/* (sessione Auth.js) + /client/[token]/* (token) + future pagine pubbliche preventivo
  • La sidebar admin (Phase 6) è l'hub di navigazione per le nuove sezioni (CRM, Preventivi, Offerte)
  • project_offers (Phase 5) già copre l'attribuzione di offerte a progetti esistenti — da rifinire, non ricostruire
  • Il flusso commerciale reale: call con lead → preventivo 3 tier (es. Signature A/B/C) in giornata → accettazione → onboarding automatico nell'hub

Constraints

  • Data Safety (LOCKED): migration solo additive su clients, projects, payments, phases — la migrazione del catalogo servizi va pianificata per consolidare senza drop/truncate
  • Architettura (LOCKED): clients.token separato e rotatable; quote_items mai esposti via client API; deliverables.approved_at immutabile; no file hosting
  • Stesso DB: tutte le nuove aree (CRM, preventivi, offerte) leggono/scrivono lo stesso Postgres — nessun servizio separato
  • Numerazione fasi: v2.0 parte da Phase 7 (v1.0 ha chiuso alla 6)

Key Decisions

Decision Rationale Outcome
Link segreto senza login per i clienti Massima semplicità — nessun account da creare, zero friction ✓ Good
Dashboard prima del flusso Claude Clienti attivi ora, la visibilità al cliente è il valore immediato ✓ Good
Preventivo: cliente vede solo il totale Il dettaglio dei prezzi è informazione commerciale riservata ✓ Good
Suite unica sotto /admin/* invece di 3 app separate Stesso DB, stesso deploy, auth unica — overhead di 3 app ingiustificato per singolo admin — Pending
Catalogo servizi unificato (una tabella services) Due cataloghi paralleli (service_catalog + offer_services) duplicano manutenzione prezzi — Pending
Tier offerte indipendenti (A/B/C separati, stesso tag) Più semplice di un meccanismo di ereditarietà; ogni tier configurato a sé — Pending
Prezzi pacchetti per-preventivo, non da catalogo Permette di alzare i prezzi nel tempo senza toccare il catalogo — Pending
Al "Vinto" le fasi dell'offerta sono COPIATE nel progetto Il progetto resta modificabile senza toccare il template offerta — Pending

Evolution

This document evolves at phase transitions and milestone boundaries.

After each phase transition (via /gsd-transition):

  1. Requirements invalidated? → Move to Out of Scope with reason
  2. Requirements validated? → Move to Validated with phase reference
  3. New requirements emerged? → Add to Active
  4. Decisions to log? → Add to Key Decisions
  5. "What This Is" still accurate? → Update if drifted

After each milestone (via /gsd-complete-milestone):

  1. Full review of all sections
  2. Core Value check — still the right priority?
  3. Audit Out of Scope — reasons still valid?
  4. Update Context with current state

Last updated: 2026-06-10 — Milestone v2.0 started (Business Operations Suite)