Files
clienthub/.planning/milestones/v2.2-phases/20-knowledge-base-cliente/20-DISCUSSION-LOG.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

2.4 KiB

Phase 20: Knowledge Base Cliente — Discussion Log

Audit trail only. Do not use as input to planning, research, or execution agents. Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.

Date: 2026-06-19 Phase: 20-knowledge-base-cliente Areas discussed: Lead-scoped o anche client?


Lead-scoped o anche client?

Q1 — FK scope della tabella

Option Description Selected
Solo lead per ora client_transcripts ha solo lead_id. Semplice, sufficiente per Phase 21. La FK client_id si aggiunge in futuro se serve.
Prepara entrambe le FK ora lead_id e client_id entrambi nullable nella tabella. Più lavoro ora, ma non serve una migration futura se vuoi trascrizioni anche per clienti esistenti.

User's choice: Prepara entrambe le FK ora Notes: L'utente preferisce prepararsi alla flessibilità futura con una sola migration ora.


Q2 — UI Phase 20 per client_id

Option Description Selected
Solo dal dettaglio lead per ora La FK client_id c'è nello schema ma non è esposta in UI in Phase 20. Si usa quando un lead è convertito — per dopo.
Anche dalla pagina admin cliente Phase 20 aggiunge il blocco transcript sia nel LeadDetail che in /admin/clients/[id]. Più lavoro, ma copre subito clienti esistenti senza lead.

User's choice: Solo dal dettaglio lead per ora Notes: L'UI Phase 20 è solo lato lead. client_id è nello schema ma non esposta.


Claude's Discretion

Le seguenti aree non sono state discusse e sono state lasciate al giudizio di Claude:

  • Metadati del transcript — Scelto: title (text, optional) + content (text, illimitato) + call_date (date). No enum tipo — il titolo libero è sufficiente.
  • Collocazione UI nel LeadDetail — Scelto: nuova sezione "Transcript" collassabile dopo le Attività, seguendo il pattern visivo esistente (Card + lista). Modal per aggiungere (come LogActivityModal).
  • Ordinamentocall_date DESC (chiamata più recente in cima).

Deferred Ideas

  • UI transcript nella pagina admin cliente (/admin/clients/[id]) — la FK è pronta, la UI è deferred post-v2.2.
  • Ricerca full-text sui transcript — fuori scope, i transcript vengono letti dall'AI in blocco.
  • Trascrizione automatica da audio — fuori scope v2.2.