Files

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

8.3 KiB

Raw Blame History

phase, plan, subsystem, tags, requires, provides, affects, tech-stack, key-files, key-decisions, patterns-established, requirements-completed, duration, completed

phase

plan

subsystem

Phase 14 Plan 02: LeadTable Attio Rewrite Summary

Rewrote LeadTable.tsx as a raw-table Attio-style database view with inline editing, a closed status dropdown preserving semantic colors, and lead tags via OptionMultiSelect; added LeadsSearch.tsx for client-side instant filtering; rewired /admin/leads and /admin/leads/[id] to the new data layer; surfaced lead tags in LeadDetail's "Profilo" card.

Performance

Duration: ~25 min
Completed: 2026-06-14T13:22:00+02:00
Tasks: 2
Files modified: 4 (+1 created)

Accomplishments

LeadTable.tsx fully rewritten: raw <table> (no shadcn Table wrapper), 8 columns (Nome/Email/Telefono/Azienda/Stato/Prossima Azione/Tag/Azioni)
EditableCell wired for name (required), email, phone, company, next_action → updateLeadField
New local StatusCell: click-to-open closed dropdown over the 6 LEAD_STAGES values only (no free-text/create option), preserving semantic STAGE_COLOR badges (won=green, lost=red, etc.) per UI-SPEC Decision 1 — implemented without modifying shared option-select.tsx
OptionMultiSelect for lead tags, wired to addLeadTag/removeLeadTag/renameLeadTag
Per-row error <tr> and "Nessun lead trovato" empty state
New LeadsSearch.tsx: instant client-side filter over name/email/company/status/tags (mirrors CatalogSearch.tsx)
page.tsx rewired to fetch getLeadsWithTags() + getLeadFieldOptions() in parallel, render LeadsSearch + CreateLeadModal, revalidate = 0
[id]/page.tsx rewired to fetch getLeadsWithTags()/getLeadFieldOptions(), locate the lead by id, pass tags/tagOptions to LeadDetail
LeadDetail.tsx "Profilo" card now includes an OptionMultiSelect for lead tags with its own run()/error-display helper, identical mutation pattern to LeadTable

Task Commits

Each task was committed atomically:

Task 1: Rewrite LeadTable.tsx as raw-table database-view (CRM-08, CRM-09) - 4887a31 (feat)
Task 2: Create LeadsSearch.tsx, rewire page.tsx, surface tags in LeadDetail.tsx - ab7fa62 (feat)

Files Created/Modified

src/components/admin/leads/LeadTable.tsx - Full rewrite: raw-table LeadRow/LeadTable, new StatusCell, EditableCell/OptionMultiSelect wiring
src/app/admin/leads/LeadsSearch.tsx - New file: client-side instant filter wrapper around LeadTable
src/app/admin/leads/page.tsx - Rewired to getLeadsWithTags()/getLeadFieldOptions() + LeadsSearch, revalidate = 0, dropped Suspense/LeadsList
src/app/admin/leads/[id]/page.tsx - Rewired to getLeadsWithTags()/getLeadFieldOptions() (dropped getLeadById), passes tags/tagOptions to LeadDetail
src/components/admin/leads/LeadDetail.tsx - Added tags/tagOptions props, OptionMultiSelect + run() helper in "Profilo" card, imports for useState/useTransition/useRouter/addLeadTag/removeLeadTag/renameLeadTag/OptionMultiSelect

Decisions Made

Followed the plan's <action> blocks essentially verbatim, including the plan's own correction to use a local StatusCell instead of OptionSelect (the plan pre-emptively documents and resolves this — not a Claude-discretion deviation, just executing the plan as written)
For [id]/page.tsx, used plan's approach (a): getLeadsWithTags().find(l => l.id === id) + getLeadFieldOptions(), calling notFound() if no match — removes the getLeadById import entirely

Deviations from Plan

Documentation-only (plan acceptance_criteria inaccuracies, not implementation defects)

1. grep -c '"Dettagli"' LeadTable.tsx expects 1, returns 0

The plan's own <action> code renders <Link href={...}>Dettagli</Link> — "Dettagli" as JSX text content, not a quoted string literal "Dettagli". The implementation matches the <action> block exactly; the acceptance grep (which looks for literal "Dettagli") was simply never going to match this code shape.
No fix needed — <behavior> and <action> blocks both specify this exact JSX form.

2. grep -c "useMemo" LeadsSearch.tsx expects 1, returns 2

LeadsSearch.tsx is a 1:1 structural port of CatalogSearch.tsx, which itself returns 2 for this same grep (1 import line + 1 usage line). Verified: grep -c "useMemo" src/app/admin/catalog/CatalogSearch.tsx also returns 2. The acceptance criterion is stale relative to its own reference implementation.
No fix needed — implementation matches the established pattern exactly.

Pre-existing, unrelated (not introduced by this plan)

3. Unused Button import in LeadDetail.tsx

npx eslint src/components/admin/leads/LeadDetail.tsx reports 1 warning: @typescript-eslint/no-unused-vars for the Button import.
Confirmed pre-existing: git show main:src/components/admin/leads/LeadDetail.tsx | grep -c '\bButton\b' returns 1 (import-only) on main as well, before this plan's edits. Not touched — out of scope per "Do not modify any other part of LeadDetail.tsx" instruction.

Total deviations: 0 implementation deviations. 2 stale plan-doc acceptance criteria (documented above, both verified against their reference analogs). 1 pre-existing lint warning (unrelated, untouched). Impact on plan: None — npx tsc --noEmit exits 0 across the whole project; npx eslint exits 0 (errors) with only the 1 pre-existing warning noted above.

Issues Encountered

None beyond the documentation-only items above.

User Setup Required

None — no new dependencies, no schema/migration changes (this plan is pure frontend wiring on top of Plan 14-01's already-applied data layer).

Next Phase Readiness

/admin/leads and /admin/leads/[id] now fully deliver CRM-08 (inline-edit database view) and CRM-09 (lead tags)
This was the only plan in Wave 2 and the last plan in Phase 14 — ready for phase-level verification (CRM-08 through CRM-12 across all 3 plans)

Phase: 14-crm-attio-style-fix Completed: 2026-06-14

Self-Check: PASSED

FOUND: src/components/admin/leads/LeadTable.tsx
FOUND: src/app/admin/leads/LeadsSearch.tsx
FOUND: src/app/admin/leads/page.tsx
FOUND: src/app/admin/leads/[id]/page.tsx
FOUND: src/components/admin/leads/LeadDetail.tsx
FOUND: .planning/phases/14-crm-attio-style-fix/14-02-SUMMARY.md
FOUND commit: 4887a31
FOUND commit: ab7fa62

8.3 KiB Raw Blame History