clienthub/.planning/REQUIREMENTS.md

# Requirements — ClientHub (v2.1 chiuso → v2.2 Sales Loop)

**Defined:** 2026-06-13 · **Reset:** 2026-06-19
**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.

v2.0 (Phases 7–10) ha consegnato catalogo unificato, offerte con fasi, preventivo pubblico e CRM pipeline (vedi MILESTONES.md, REQUIREMENTS.md archiviato in `.planning/milestones/v2.0-REQUIREMENTS.md`). v2.1 rifà la UX di catalogo/offerte in stile database-view, ristruttura il workspace progetto, ricostruisce il CRM in stile Attio e chiude il loop commerciale con un builder preventivi AI.

> **RESET 2026-06-19 — milestone v2.2 "Sales Loop".** v2.1 ha consegnato Offer Studio (Phase 11+12) e CRM Attio (Phase 14). Le fasi residue v2.1 — **13 (Servizi Attivi), 15 (Dashboard Revenue), 16/17 (Proposal AI originali)** — sono state **congelate/abbandonate/ri-scopate** dopo che l'utente ha articolato il flusso commerciale reale (vedi piano `.claude/plans/glittery-sprouting-pudding.md`). Il nuovo north-star è il **loop di vendita**: lead in pipeline Kanban → transcript call → agente AI genera preventivo → pagina pubblica `/preventivo/[slug]` → vinto/perso. Requirements attivi: sezione **v2.2** più sotto.

## Offer Studio — Catalogo & Offerte (v1)

| ID | Requirement | Status |
|----|-------------|--------|
| OFFER-07 | L'utente vede ed edita il catalogo `services` come tabella con inline editing (click su cella → edit → invio salva) | Complete |
| OFFER-08 | L'utente assegna tag multi-select a servizi/offerte, creando nuovi tag al volo senza uscire dalla tabella | Complete |
| OFFER-09 | L'utente aggiunge un nuovo servizio/offerta tramite riga vuota in fondo alla tabella (nome + invio) | Complete |
| OFFER-10 | L'utente filtra/cerca servizi e offerte istantaneamente (ricerca client-side, nessun reload) | Complete |
| OFFER-11 | L'admin compone un'offerta a 3 tier (A/B/C) assegnando i servizi del catalogo unificato `services` tramite matrice di checkbox (servizio × tier); il totale servizi di ogni tier si aggiorna live | Complete |
| OFFER-15 | Ogni offerta ha tag su 4 dimensioni (categoria, ticket, tipo, obiettivo) creabili al volo, riusando il sistema tag polimorfico di Phase 11 | Complete |
| OFFER-16 | Per ogni tier l'admin imposta un "prezzo pubblico" manuale, distinto e indipendente dal totale dei servizi | Complete |
| OFFER-17 | Ogni offerta ha una promessa di trasformazione strutturata (Cliente Ideale / Risultato / tempo / Pain / Metodo) | Complete |
| OFFER-18 | La lista offerte è filtrabile per categoria e supporta l'archiviazione (mostra/nascondi archiviate) | Complete |
| OFFER-13 | I dati legacy di `service_catalog` e `offer_services` sono consolidati in `services` senza perdita (migration additiva) | Complete |

## Workspace Progetto — Servizi Attivi (ex Phase 13 — CONGELATO v2.2)

> Congelato dal reset 2026-06-19: tocca il portale post-vendita che l'utente vuole lasciare invariato. Ripescabile in futuro se serve il tracking ricavi ricorrenti. (PROJ-10 "rimuovi Forecast" è confluito in CLEAN-01 v2.2.)

| ID | Requirement | Status |
|----|-------------|--------|
| PROJ-06 | La tab "Preventivo" è rimossa dal workspace progetto (solo UI — `quote_items` resta intatta, `accepted_total` resta editabile via tab Pagamenti) | Congelato (v2.2) |
| PROJ-07 | La tab "Offerte" diventa "Servizi attivi": mostra tutte le offerte assegnate al progetto (`project_offers`) | Congelato (v2.2) |
| PROJ-08 | L'utente marca ogni "servizio attivo" come one-shot o ricorrente mensile | Congelato (v2.2) |
| PROJ-09 | Per i servizi ricorrenti, l'utente registra in quali mesi è stata incassata la fattura (schema nuovo, additivo — UI può essere minimale) | Congelato (v2.2) |
| PROJ-10 | La pagina "Forecast" e la relativa voce di sidebar sono rimosse | → CLEAN-01 (v2.2) |

## CRM Custom Attio-style (v1)

| ID | Requirement | Status |
|----|-------------|--------|
| CRM-08 | La tabella lead (`/admin/leads`) supporta inline editing dei campi principali (status, next_action, ecc.) senza apertura modale | Complete |
| CRM-09 | L'utente assegna tag multi-select ai lead, creando nuovi tag al volo | Complete |
| CRM-10 | Il `FollowUpWidget` è in italiano, coerente col resto dell'app | Complete |
| CRM-11 | Il form lead (`LeadForm`) valida i campi senza workaround di type-relaxation su react-hook-form | Complete |
| CRM-12 | Il flusso `SendQuoteModal` (preventivo esistente vs nuovo) non contiene rami di codice irraggiungibili | Complete |

## Dashboard — Revenue Stats (ex Phase 15 — ABBANDONATO v2.2)

> Abbandonato dal reset 2026-06-19: mockup mai arrivato, valore dubbio nel nuovo flusso. L'esigenza analytics è coperta da CLEAN-03 (fusione `/admin/analytics` nella dashboard, no fase dedicata).

| ID | Requirement | Status |
|----|-------------|--------|
| DASH-11 | La Dashboard admin mostra le statistiche di revenue mensile (ex `/admin/forecast`, calcolate da `project_offers`) | Dropped (v2.2 → CLEAN-03) |

## Proposal AI — versione v2.1 originale (SUPERSEDED da v2.2)

> Ri-scopata dal reset 2026-06-19 nelle fasi v2.2 (PIPE/KB/AI/PUB) con il flusso chiaro + l'aggiunta dei transcript (che mancava). PROP-03 (Stripe Payment Link) e PROP-04 (auto-provisioning al "Vinto") restano backlog: non nel loop minimo, da rivalutare dopo R5.

| ID | Requirement | Status |
|----|-------------|--------|
| PROP-01 | L'admin avvia un builder AI che genera una proposta a partire da cliente + offerta(e) selezionata(e) + note extra fornite manualmente | Superseded → AI-01/AI-02 (v2.2) |
| PROP-02 | La pagina pubblica `/quote/[token]` è ridisegnata (HTML/CSS) per presentare la proposta generata | Superseded → PUB-01 (v2.2) |
| PROP-03 | Ogni offerta/preventivo ha un campo "link di pagamento" (Stripe Payment Link) mostrato come CTA nella pagina pubblica | Backlog (post-R5) |
| PROP-04 | All'accettazione del preventivo, il sistema crea automaticamente cliente + progetto, copia le fasi dall'offerta e configura 1-4 pagamenti (ex-Phase 11 WIN-01..06) | Backlog (post-R5) |
| PROP-05 | Il sistema invia via email (Resend) il link della proposta pubblica al lead (ex-Phase 12) | Superseded → PUB-03 (v2.2) |

## v2.2 — Sales Loop: Lead → AI → Preventivo (ATTIVO)

> Reset 2026-06-19. Il flusso commerciale articolato dall'utente sostituisce le fasi residue v2.1. Fasi eseguite in ordine R1→R5 (numerazione GSD continua: Phase 18→22). Le fasi 11/12/14 restano completate.

### Cleanup & Consolidamento (Phase 18 / R1)

| ID | Requirement | Status |
|----|-------------|--------|
| CLEAN-01 | La pagina Forecast (`/admin/forecast`) e la sua voce di sidebar sono rimosse | Complete |
| CLEAN-02 | Il quote builder manuale (`/admin/quotes/new`) e il suo entry point sono rimossi (superato dall'agente AI) | Complete |
| CLEAN-03 | Le statistiche di `/admin/analytics` sono fuse nella Dashboard `/admin` (vista unica); la rotta duplicata è eliminata | Complete |
| CLEAN-04 | Le fasi v2.1 residue (13/15/16/17) sono archiviate/ri-scopate nel planning | Complete |

### Pipeline CRM Kanban (Phase 19 / R2)

| ID | Requirement | Status |
|----|-------------|--------|
| PIPE-01 | I lead sono visualizzabili in una board Kanban stile Pipedrive con colonne per stage e drag-drop per cambiare stage | Complete |
| PIPE-02 | Spostare un lead nelle colonne "Vinto"/"Perso" è il cambio-stato manuale dell'esito | Complete |

### Knowledge Base Cliente — Transcript (Phase 20 / R3)

| ID | Requirement | Status |
|----|-------------|--------|
| KB-01 | Schema additivo per memorizzare transcript datati e multipli per lead/cliente | Complete |
| KB-02 | L'admin incolla ed elenca i transcript (storico ordinato per data) nel dettaglio lead/cliente | Complete |

### Agente AI — Generazione preventivo (Phase 21 / R4)

| ID | Requirement | Status |
|----|-------------|--------|
| AI-01 | L'admin seleziona cliente + offerta; l'agente AI (Claude) legge i transcript + i dati dell'offerta e genera una bozza di preventivo personalizzata | Complete |
| AI-02 | L'admin rivede ed edita la bozza generata prima di pubblicarla | Complete |

### Pagina pubblica preventivo + email (Phase 22 / R5)

| ID | Requirement | Status |
|----|-------------|--------|
| PUB-01 | La proposta generata è pubblicata come pagina pubblica HTML/CSS a `/preventivo/[slug]` (evolve la meccanica di `/quote/[token]`) | Complete |
| PUB-02 | Il cliente accetta/rifiuta dalla pagina; l'esito si riflette nel CRM (conferma vinto/perso manuale lato admin) | Complete |
| PUB-03 | Il link della proposta viene inviato al lead via email (Resend) | Not implemented — deferred to backlog v2.3 |

## v2 Requirements (Deferred)

### Catalogo Avanzato

- **OFFER-12**: Import CSV/Notion one-shot per popolare servizi/offerte esistenti (solo seed iniziale, non sync continuo) — *rimandato il 2026-06-14 su decisione utente ("per ora saltiamo"); rientra nel filone "import dati da Notion" da valutare in una fase futura*
- **OFFER-14**: Sezioni analitiche stile Notion per le offerte (psicologia, rating, performance)

### Accesso Cliente

- **AUTH-OTP-01**: Accesso dashboard cliente via OTP email (design pronto, vedi memoria `project_clienthub_otp_access`)

### Architettura

- **ARCH-01**: Split di un modulo "compartimento stagno" in deploy separato (solo se il modulo cresce abbastanza da giustificarlo)

## Out of Scope

| Feature | Reason |
|---------|--------|
| Fatturazione e invio fatture | Solo stato pagamenti, gestione contabile fuori |
| App mobile nativa | Solo web responsive |
| Multi-utente con team | Solo admin singolo per ora |
| Prezzi singoli visibili al cliente | Vede solo il totale accettato (vincolo LOCKED) |
| File hosting | Documenti solo come URL esterni (vincolo v1, ancora valido) |
| Database esterno o Excel come fonte dati | Postgres unica fonte di verità — il problema è la UX, non il dato |
| Notion-clone completo (sezioni psicologia/rating/performance) | Troppo complesso per v1, vedi v2 Requirements |
| Deploy separati per modulo (architettura OMC multi-app) | Non finché un modulo non cresce abbastanza da giustificarlo |

## Traceability

Popolata dal roadmapper durante la creazione della roadmap.

| Requirement | Phase | Status |
|-------------|-------|--------|
| OFFER-07 | Phase 11 | Complete |
| OFFER-08 | Phase 11 | Complete |
| OFFER-09 | Phase 11 | Complete |
| OFFER-10 | Phase 11 | Complete |
| OFFER-13 | Phase 11 | Complete |
| OFFER-11 | Phase 12 | Complete |
| OFFER-15 | Phase 12 | Complete |
| OFFER-16 | Phase 12 | Complete |
| OFFER-17 | Phase 12 | Complete |
| OFFER-18 | Phase 12 | Complete |
| OFFER-12 | Deferred (v2) | Rimandato 2026-06-14 |
| PROJ-06 | Phase 13 | Congelato (v2.2) |
| PROJ-07 | Phase 13 | Congelato (v2.2) |
| PROJ-08 | Phase 13 | Congelato (v2.2) |
| PROJ-09 | Phase 13 | Congelato (v2.2) |
| PROJ-10 | Phase 13 | → CLEAN-01 |
| CRM-08 | Phase 14 | Complete |
| CRM-09 | Phase 14 | Complete |
| CRM-10 | Phase 14 | Complete |
| CRM-11 | Phase 14 | Complete |
| CRM-12 | Phase 14 | Complete |
| DASH-11 | Phase 15 | Dropped (→ CLEAN-03) |
| PROP-03 | Phase 16 | Backlog (post-R5) |
| PROP-04 | Phase 16 | Backlog (post-R5) |
| PROP-01 | Phase 17 | Superseded → AI-01/02 |
| PROP-02 | Phase 17 | Superseded → PUB-01 |
| PROP-05 | Phase 17 | Superseded → PUB-03 |
| CLEAN-01 | Phase 18 (R1) | Complete |
| CLEAN-02 | Phase 18 (R1) | Complete |
| CLEAN-03 | Phase 18 (R1) | Complete |
| CLEAN-04 | Phase 18 (R1) | Complete |
| PIPE-01 | Phase 19 (R2) | Complete |
| PIPE-02 | Phase 19 (R2) | Complete |
| KB-01 | Phase 20 (R3) | Complete |
| KB-02 | Phase 20 (R3) | Complete |
| AI-01 | Phase 21 (R4) | Complete |
| AI-02 | Phase 21 (R4) | Complete |
| PUB-01 | Phase 22 (R5) | Complete |
| PUB-02 | Phase 22 (R5) | Complete |
| PUB-03 | Phase 22 (R5) | Not implemented — deferred to backlog |

---
*Requirements defined: 2026-06-13*
*Last updated: 2026-06-20 — v2.2 complete: PIPE/KB/AI/PUB-01/02 tutti Complete; PUB-03 (email Resend) deferred to backlog v2.3*