simone/clienthub
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
31237da11c3d9f26b6ea3ef36c4cbf624f657696
clienthub/.planning/REQUIREMENTS.md
T
simone f7eb7eec23 docs(planning): archivia v2.1/v2.2/v2.3 e documenta v2.4 
.planning/ documentava in dettaglio cio che era vecchio e per niente cio
che e in produzione: le fasi 11-22 (v2.1 e v2.2, chiuse a giugno) erano
ancora in phases/ mentre v1.0 e v2.0 stavano gia in milestones/, e il
lavoro degli ultimi due mesi - gate OTP e ciclo di vita dei retainer, cioe
quello che gira su hub.iamcavalli.net - non aveva nessuna cartella.

- phases/{11,12,14} -> milestones/v2.1-phases/, phases/{18..22} ->
  milestones/v2.2-phases/. Ora phases/ contiene solo la milestone in
  corso, che e quello che state.cjs conta per il progresso
- v2.1-ROADMAP.md ricostruito: era l'unica milestone senza archivio,
  interrotta dal reset del 19/06 e mai chiusa formalmente
- v2.3-ROADMAP.md + v2.3-REQUIREMENTS.md: v2.3 e stata eseguita fuori dal
  ciclo GSD, non esistono PLAN/SUMMARY per fase. L'archivio E la doc
- REQUIREMENTS.md riscritto per v2.4 con il backlog reale
- phases/13 e phases/26: SUMMARY ricostruiti da commit, migration e
  STATUS.md. 26 e il primo numero libero
- research/: cancellate 4 varianti dello stesso PITFALLS e FEATURES/
  SUMMARY, superati da PROJECT.md. Diverse anti-feature erano ormai
  contraddette dai fatti (il Kanban e stato costruito in Phase 19,
  l'email in v2.3, il time tracking esiste)
- cancellati UI-RULES.md e DESIGN-SYSTEM.md (CLAUDE.md li dichiara
  superseded: impongono l'inverso della regola attuale) e HANDOFF.md,
  fermo al 13/06
- SECURITY-*.md -> security/: audit chiuso, ma i report restano la doc di
  cosa e stato ruotato e perche
- PROJECT.md/MILESTONES.md/ROADMAP.md allineati: milestone corrente v2.4,
  sessione OTP 90gg non 30, migrazioni fino alla 0016

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 22:38:36 +02:00

3.9 KiB
Raw Blame History

Requirements: ClientHub v2.4 Post-vendita

Definiti: 2026-08-08 (ricostruiti a posteriori — v2.4 è partita senza requisiti scritti) 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.

Milestone precedente: v2.3 Email & Accesso, shipped 2026-07-29.

Consegnati

Ciclo di vita dei servizi ricorrenti (Phase 13) — ✅ in produzione 2026-08-01

  • RET-01: Un'offerta ricorrente assegnata a un progetto ha uno stato (attivo / sospeso / cessato) e una data di fine opzionale
  • RET-02: L'admin può sospendere, riattivare e cessare un retainer dalla tab Offerte del progetto
  • RET-03: Il forecast a 12 mesi smette di sommare un retainer sospeso, cessato o oltre la sua end_date
  • RET-04: Lo storico del venduto (getOffersSoldBreakdown) non filtra per stato — escludere le cessate riscriverebbe il passato
  • RET-05: Il cliente vede stato, "attivo dal / fino al" e "canone mensile"; le offerte cessate non gli arrivano

Anteprima admin e login (Phase 26) — ✅ in produzione 2026-08-08

  • PREV-01: L'admin può aprire il portale di un cliente in sola lettura senza passare dal gate OTP (?preview=1 + sessione Auth.js valida)
  • PREV-02: In anteprima approvazione e composer messaggi sono disattivati a livello di UI
  • AUTH-09: Il campo password del login admin ha un toggle mostra/nascondi

Backlog v2.4+ (non pianificati)

Ereditati dalle chiusure di milestone precedenti, nessuno in corso:

  • SEND-01 / SEND-02 — Invio del link /preventivo/[slug] via email dall'admin. Il mailer (src/lib/mailer.ts) è già pronto e in produzione dalla v2.3: manca solo il pulsante e l'action. Rinviati il 2026-07-28.
  • PROP-03 — Stripe Payment Link sul deck pubblico del preventivo. Rinviato al kickoff v2.3.
  • PROP-04 — Auto-provisioning di cliente / progetto / fasi al passaggio del lead a "Vinto". Rinviato al kickoff v2.3.
  • RET-06 — Canoni mensili tracciabili (agosto pagato / settembre no). Serve una tabella nuova: payments è protetta dai vincoli di Data Safety e la sua riscalatura è pensata per i piani una tantum. Fuori scope di Phase 13.
  • OFFER-14 — Sezioni analitiche stile Notion sull'offerta. Rinviato al kickoff v2.1.
  • ARCH-01 — Split del modulo "compartimento stagno" in un deploy separato. Solo se il modulo cresce.
  • DEBT-01 — Debito design: ~40 file, ~450 occorrenze di palette Tailwind raw e hex literal al posto dei token semantici. I cluster: /admin/projects/[id] e i suoi tab (~182), /admin/offers/[id]/edit (~79), /admin/clients/[id] (~59), tutto /quote/[token] (~48, ed è rivolto al cliente), ChatPanel del portale (37), più ui/dialog.tsx che propaga il look vecchio a ogni modale. Esclusi perché legittimi: AdminSidebar (eccezione brand documentata), src/lib/mailer.ts (HTML email, niente CSS var), i colori di stato di StatusBadge (sanzionati dal design system, hanno già le varianti dark:). Misurato il 2026-08-08 — la stima precedente di "11 pagine" era sottostimata.
  • DEBT-02 — Tabelle legacy service_catalog / offer_services / offer_micro_services come deadweight; createService / serviceSchema dead code in src/app/admin/catalog/actions.ts.

Aperto, non un requisito

Whitelist del portale vuota per 3 clienti su 4. La migration 0015 ha seedato solo mario@test.it (cliente di test). Protocollo Estetico, Caruso Speaker e Teckell hanno whitelist vuota e finché lo è il loro portale non è accessibile. Si popola da /admin/clients/<id> → "Accessi al portale", poi va reinviato il link.

Fuori scope

  • File hosting (vincolo LOCKED #5: i documenti restano URL esterni).
  • Tabella utenti / multi-admin: l'auth resta una singola credenziale da env.
Reference in New Issue View Git Blame Copy Permalink