docs(handoff): new direction — Offer Studio + Proposal AI, decisions and next-session plan
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
+33
-28
@@ -4,43 +4,48 @@ Living document — update at the end of each session so the next one can resume
|
||||
|
||||
---
|
||||
|
||||
## 2026-06-11 (sera) — Phase 10 redo COMPLETATO, root cause trovata
|
||||
## 2026-06-12 — Nuova direzione: "Offer Studio" + "Proposal AI" (decisa, da pianificare)
|
||||
|
||||
### Root cause del crash (diversa dall'ipotesi del handoff precedente)
|
||||
### Contesto della decisione
|
||||
|
||||
Il DB di produzione (Coolify, container `xwkk0040w0kk0gsgcgog8owk`, db `clienthub`) **non aveva NESSUNA migration applicata dopo la 0000**: mancavano `services` (0001), `leads`/`offer_phases`/`offer_phase_services`/`quotes` (0003), le colonne quotes (0004). Le summary di Phase 7/8 dicevano "migration pending connectivity" e nessuno le ha mai applicate.
|
||||
L'utente ha mostrato due riferimenti:
|
||||
|
||||
Conseguenze: catalogo (→`services`), quote builder e `/quote/[token]` (→`quotes`) erano **già rotti in produzione prima di Phase 10**. Il deploy di Phase 10 ha solo aggiunto il crash della dashboard (FollowUpWidget→`leads`). Il rollback a `0bca8a6` ha mascherato il sintomo dashboard ma /quote/[token] dava ancora 500 (verificato con token 21-char valido).
|
||||
1. **Diagramma architettura del suo amico (OMC)**: più app indipendenti (Hub, AI Agents, Content Marketing Tool, New Tool) che condividono UN database (Supabase), deploy da GitHub. Concetto: "compartimenti stagni" — aggiungere un'app non rompe le altre.
|
||||
2. **Il suo Notion attuale per le offerte** (Offer Builder): DB Attività/Servizi con tag+prezzi, DB Offerte con sezioni (panoramica, strategia, scala valore, promessa, psicologia, pricing, vendita, rating, performance). Lo usa oggi ma vuole portare il flusso dentro ClientHub.
|
||||
|
||||
NB: l'app NON è su Vercel — Gitea (`git.iamcavalli.net`) → Coolify self-hosted. Il problema non era di piattaforma; nessun motivo di migrare a Replit.
|
||||
### Problema dichiarato
|
||||
|
||||
### Cosa è stato fatto (redo staged)
|
||||
Il catalogo/offerte che abbiamo costruito è "lento e macchinoso" rispetto a Notion: creare un'offerta, taggarla, metterci servizi è scomodo. L'utente chiedeva se servisse un DB esterno o import da Excel.
|
||||
|
||||
1. **Stage A** — commit `5aa6614`: deps `@radix-ui/react-dialog@^1.1.16` + `date-fns@^4.4.0` + `ui/dialog.tsx`/`ui/form.tsx`. Deployato e verificato.
|
||||
2. **Stage B** — migrations **0001+0003+0004+0005 applicate in unica transazione atomica** al DB prod via `ssh root@178.104.27.55` → `docker exec psql` (porta 54321 chiusa dal firewall dall'esterno; SSH ok). Verificato: 25 tabelle, `leads` con 12 colonne, righe protette intatte (4 clients / 5 projects / 13 payments / 6 phases). `/quote/[token]` 500→404. Script riusabile: `scripts/push-phase10-migration.ts` (funziona solo dal server o con tunnel).
|
||||
3. **Stage C** — commit `008a434`: tutto il modulo CRM da `phase10-wip` (schema, lead-service/validators, /admin/leads, modali, FollowUpWidget, sidebar). Build pulita, push fatto, deploy Coolify in corso a fine sessione.
|
||||
### Decisioni prese (vincolanti per la pianificazione)
|
||||
|
||||
### Verificato a fine sessione (2026-06-11 sera)
|
||||
1. **NO database esterno, NO Excel come fonte dati.** Postgres resta l'unica fonte di verità (lezione del 2026-06-11: mai due fonti disallineate). Il problema è il layer UX, non il dato.
|
||||
2. **Rifare la UX di catalogo + offerte in stile "database view" Notion/Airtable**, su misura:
|
||||
- tabella con inline editing (click su cella → edit → invio)
|
||||
- tag multi-select colorati con creazione al volo
|
||||
- quick-add (riga vuota in fondo, nome + invio)
|
||||
- filtri/ricerca istantanei
|
||||
- composizione offerta: apri offerta → spunti/trascini servizi dal catalogo a lato → totale live (`@dnd-kit` già nel progetto)
|
||||
- **import CSV una tantum** solo per seedare i pacchetti esistenti (porta d'ingresso, non fonte di verità)
|
||||
3. **Complessità Notion NON replicata in v1**: solo servizi (tag/prezzo/costo), offerte (tag/pricing/stato), composizione. Sezioni analitiche (psicologia, rating, performance) dopo.
|
||||
4. **Architettura a compartimenti stagni = quello che già facciamo**, formalizzato: un'unica app Next.js, moduli isolati (route group + service layer propri) su DB condiviso; migrations SOLO additive. Niente deploy separati per ora; se un modulo cresce, si stacca con deploy proprio sullo stesso DB (modello OMC).
|
||||
5. **Pipeline finale**: Catalogo servizi → Offer Builder → **Preventivo Builder AI** (pesca cliente + offerta + info extra fornite dall'utente, genera proposta) → pagina pubblica HTML/CSS (base già live su `/quote/[token]`) → **link pagamento in fondo** (Stripe Payment Link come campo dell'offerta).
|
||||
6. **Ordine**: prima la UX veloce del dato ("Offer Studio", che assorbe anche i fix CRM/design segnalati ieri), poi l'AI ("Proposal AI"). L'AI è l'ultimo miglio.
|
||||
|
||||
- [x] Deploy Stage C live — **utente conferma: le pagine CRM sono visibili in produzione**
|
||||
- [ ] `git branch -D phase10-wip` quando il redo è considerato definitivo
|
||||
### Prossima sessione (l'utente passa a Sonnet per l'esecuzione)
|
||||
|
||||
### PRIORITÀ prossima sessione — fix CRM prima di andare avanti
|
||||
1. **Ripianificare la roadmap GSD**: definire milestone/fasi "Offer Studio" e "Proposal AI" (sostituiscono/ridefiniscono le vecchie Phase 11 auto-provisioning e 12 Resend — da ridiscutere dove collocarle). Usare `/gsd-new-milestone` o ridefinire le fasi correnti — far decidere all'utente.
|
||||
2. **Raccogliere dall'utente l'elenco puntuale dei problemi CRM** visti il 2026-06-11 (design + funzionali + strutturali) e incorporarli nel ridisegno, NON fixarli in isolamento.
|
||||
3. L'utente vuole **fornire un suo design/mockup** per le dashboard ("belle e utili") — chiederglielo prima di disegnare la UI; usarlo come contratto UI della fase (`/gsd-ui-phase`).
|
||||
4. Candidati fix già noti da ieri (se si toccano quelle aree): FollowUpWidget in inglese (resto app in italiano), LeadForm 365 righe con type-relaxation su react-hook-form, SendQuoteModal logic flow sistemato in fretta.
|
||||
|
||||
L'utente ha visto le pagine e segnala problemi su tre fronti, **da sistemare PRIMA di Phase 11**:
|
||||
---
|
||||
|
||||
1. **Design** — aspetto/UI delle pagine CRM (da raccogliere dettagli a inizio sessione)
|
||||
2. **Funzionali** — comportamenti errati (da raccogliere dettagli)
|
||||
3. **Strutturali** — organizzazione/architettura delle pagine (da raccogliere dettagli)
|
||||
## 2026-06-11 (sera) — Phase 10 redo COMPLETATO, root cause risolta (storico)
|
||||
|
||||
Inizia la sessione chiedendo l'elenco puntuale dei problemi (o screenshot), poi fixare in ordine strutturale → funzionale → design. Candidati noti: FollowUpWidget in inglese ("Require Follow-up", "All leads are up to date!") mentre il resto dell'app è in italiano; LeadForm da 365 righe con type relaxation workaround su react-hook-form; SendQuoteModal aveva avuto un fix di logic flow frettoloso.
|
||||
|
||||
### Prossimi passi (dopo i fix)
|
||||
|
||||
- `/gsd-plan-phase 11` e `/gsd-plan-phase 12` — i planning folder non sono mai stati committati, vanno rigenerati (Phase 11: auto-provisioning con `winLead(leadId, quoteId)` idempotente keyed `SHA256(leadId+quoteId)`; Phase 12: Resend email + quote expiration)
|
||||
- Eventuale cherry-pick di `5d75752` (sidebar "App shortcuts") se ancora desiderato — dangling, recuperabile da reflog
|
||||
- **Regola da ora in poi**: ogni phase con migration → applicare al DB prod PRIMA del push del codice (le migration qui sono manuali, niente runner automatico)
|
||||
|
||||
### Hash utili
|
||||
|
||||
`5aa6614` (Stage A) · `008a434` (Stage C) · `phase10-wip` = `8e2752a` (originale recuperato) · `5d75752` (sidebar shortcuts, ancora dangling)
|
||||
- **Root cause del crash post-deploy Phase 10**: il DB prod non aveva NESSUNA migration dopo la 0000 (mancavano `services`, `leads`, `offer_phases`, `quotes`…). Catalogo e quote già rotti prima di Phase 10; il deploy Phase 10 ha aggiunto il crash dashboard (FollowUpWidget→leads). NON era un problema di piattaforma (l'app è Gitea→Coolify, non Vercel).
|
||||
- **Fix**: migrations 0001+0003+0004+0005 applicate atomicamente al DB prod via `ssh root@178.104.27.55` → `docker exec -i xwkk0040w0kk0gsgcgog8owk psql` (porta 54321 firewallata dall'esterno, si passa da SSH). Dati protetti verificati intatti (4 clients / 5 projects / 13 payments / 6 phases).
|
||||
- **Redo Phase 10 deployato**: commit `5aa6614` (deps+UI primitives) e `008a434` (modulo CRM completo). Utente conferma pagine visibili in prod.
|
||||
- **REGOLA**: le migration qui sono manuali — applicare al DB prod PRIMA di pushare codice che usa il nuovo schema. Pattern: `cat migration.sql | ssh root@178.104.27.55 "docker exec -i xwkk0040w0kk0gsgcgog8owk sh -c 'psql -U \$POSTGRES_USER -d clienthub -v ON_ERROR_STOP=1 --single-transaction'"` (verificare prima che sia additive-only).
|
||||
- Branch `phase10-wip` (= `8e2752a`) cancellabile quando il redo è considerato definitivo. Dangling ancora recuperabile: `5d75752` (sidebar App shortcuts).
|
||||
- Script riusabile: `scripts/push-phase10-migration.ts` (solo dal server o con tunnel).
|
||||
|
||||
Reference in New Issue
Block a user