simone
f7eb7eec23
.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>
8.7 KiB
Phase 11: Catalog Database-View UX & Legacy Consolidation - 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-13 Phase: 11-catalog-database-view-ux-legacy-consolidation Areas discussed: Consolidamento offer_services — portata, Architettura sistema tag, Destino del campo 'category', Tabella database-view — colonne e comportamenti
Consolidamento offer_services — portata
Investigazione preliminare: offer_services/offer_micro_services non sono solo "legacy morti" — alimentano attivamente /admin/offers e la sezione OffersSection lato cliente (prezzo cumulativo). Questo ha cambiato la portata della domanda rispetto all'assunzione iniziale ("consolidamento semplice").
Portata del consolidamento
| Option | Description | Selected |
|---|---|---|
| Solo copia dati (audit trail) | Migrazione additiva: copia righe in services con migrated_from/migrated_id (pattern Phase 7), zero behavior change a /admin/offers e OffersSection |
✓ |
| Rewiring completo | /admin/offers e OffersSection leggono/scrivono direttamente da services in questa fase |
User's choice: Solo copia dati (audit trail) Notes: Coerente con Data Safety LOCKED + "compartimenti stagni" + lezione Phase 10 (crash da disallineamento sorgenti dati). Il rewiring completo è deferito a Phase 12.
Tag automatico, status quo /admin/offers, verifica migrazione (batch di 3 domande)
| Option | Description | Selected |
|---|---|---|
| Sì, tag automatico | Le righe migrate da offer_services ricevono il tag "Offerta" per distinguerle nel catalogo unificato |
✓ |
| No tag | Nessuna marcatura delle righe migrate da offer_services |
| Option | Description | Selected |
|---|---|---|
| Status quo (legacy) | /admin/offers continua a scrivere in offer_services/offer_micro_services come oggi |
✓ |
| Rewire subito | /admin/offers viene aggiornato in questa fase per usare services |
| Option | Description | Selected |
|---|---|---|
| Solo verifica one-shot | Conteggio righe via script/log durante la migrazione (come Phase 7), nessun indicatore permanente | ✓ |
| Badge UI permanente | Indicatore visibile in /admin/catalog che mostra lo stato della migrazione |
User's choice: Tag automatico "Offerta" + status quo su /admin/offers + verifica one-shot
Notes: Il tag "Offerta" sarà un tag normale del pool (vedi area successiva), non un marcatore di sistema.
Architettura sistema tag
Investigazione preliminare: OFFER-08 (Phase 11, tag catalogo) e CRM-09 (Phase 14, tag lead) richiedono entrambi "tag multi-select con creazione al volo". La tabella comments (entity_type/entity_id polimorfico) è un precedente diretto per una junction riusabile.
Tabella tags condivisa ora vs solo catalogo
| Option | Description | Selected |
|---|---|---|
| Condiviso ora (tags + junction polimorfica) | Nuova tabella tags + junction entity_type/entity_id (pattern comments), riusabile da Phase 14 senza rifare lo schema |
✓ |
| Solo catalogo | Tabella service_tags dedicata, da generalizzare eventualmente in Phase 14 |
User's choice: Condiviso ora (tags + junction polimorfica) Notes: Build-once-reuse-later — schema pronto ora, UI lead arriva in Phase 14.
Namespace tag, colore badge, protezione tag "Offerta" (batch di 3 domande)
| Option | Description | Selected |
|---|---|---|
| Scoped per entity_type | I tag del catalogo (services) e i tag dei lead (futuro) sono pool separati, anche su tabella tags condivisa |
✓ |
| Pool globale unico | Tutti i tag condivisi tra tutte le entity_type, nessuna separazione |
| Option | Description | Selected |
|---|---|---|
| Derivato dal nome (no DB) | Colore badge calcolato via hash nome→palette fissa (6-8 colori pastello da DESIGN-SYSTEM.md), nessuna colonna color |
✓ |
| Colonna color in tags | Colore scelto/salvato esplicitamente per ogni tag |
| Option | Description | Selected |
|---|---|---|
| Tag normale | Il tag "Offerta" (auto-applicato alle righe migrate) è un tag normale del pool, rinominabile/eliminabile come ogni altro | ✓ |
| Tag protetto/system | Il tag "Offerta" non può essere rinominato/eliminato dall'utente |
User's choice: Scoped per entity_type + colore derivato dal nome + tag "Offerta" normale
Notes: Nessuna colonna extra su tags oltre a nome/entity_type — palette e hashing sono dettagli di implementazione (Claude's Discretion).
Destino del campo 'category'
Relazione tra category e tags
| Option | Description | Selected |
|---|---|---|
| Campo separato | services.category resta testo libero indipendente, accanto ai tag multi-select — due dimensioni di classificazione |
✓ |
| Migrato/fuso nei tag | category viene convertito in tag e la colonna rimossa |
User's choice: Campo separato Notes: Categoria primaria + tag flessibili sono concetti distinti, entrambi utili nella tabella.
Servizi senza category
| Option | Description | Selected |
|---|---|---|
| Nessun tag di default | Servizi senza category restano senza tag corrispondente |
✓ |
| Tag automatico "Senza categoria"/"Generale" | Creato e applicato automaticamente ai servizi senza categoria |
User's choice: Nessun tag di default Notes: Evita di popolare il pool tag con un tag "rumore" che non aggiunge informazione.
Tabella database-view — colonne e comportamenti
Colonna "Descrizione"
| Option | Description | Selected |
|---|---|---|
| Colonna piena, click-to-edit inline | Testo troncato con ellipsis, click espande in textarea inline, stesso pattern EditableCell delle altre colonne |
✓ |
| Spostata fuori riga | Descrizione visibile solo in un dettaglio/modal separato |
User's choice: Colonna piena, click-to-edit inline Notes: Coerente con lo stile Notion/Airtable — nessuna riga secondaria o modal.
Quick-add row (OFFER-09)
| Option | Description | Selected |
|---|---|---|
| Nome + invio → riga editabile con prezzo €0,00 | Scrivere solo il nome e premere invio crea il servizio con unit_price = 0; la riga diventa subito normale ed editabile, prezzo corretto inline dopo |
✓ |
| Form esteso prima del salvataggio | La quick-add row richiede tutti i campi minimi prima di creare la riga |
User's choice: Nome + invio → riga editabile con prezzo €0,00 Notes: Minimizza l'attrito di inserimento, coerente con "no modali".
Servizi disattivati (active=false)
| Option | Description | Selected |
|---|---|---|
| Visibili attenuati, in fondo sotto divisore | Restano nella tabella con opacità ridotta (comportamento attuale), ma ordinati sotto una riga divisoria che li separa dai servizi attivi | ✓ |
| Nascosti di default con filtro toggle | Non mostrati a meno che l'utente non attivi un filtro "mostra inattivi" |
User's choice: Visibili attenuati, in fondo sotto divisore Notes: Mantiene visibilità storica senza nascondere dati, separazione visiva chiara.
Colonna "azioni"
| Option | Description | Selected |
|---|---|---|
| Nessuna colonna azioni — stato come cella inline | Attivo/disattivo diventa toggle/checkbox cliccabile inline; tutte le modifiche via click-to-edit, zero bottoni per riga | ✓ |
| Colonna azioni con bottoni | Bottoni espliciti (edit/toggle/elimina) per riga |
User's choice: Nessuna colonna azioni — stato come cella inline Notes: Stile Notion/Airtable puro, coerente con DESIGN-SYSTEM.md (nessuna "azione riga-per-riga" salvo bulk in Phase 12+).
Claude's Discretion
- Implementazione esatta dei componenti
EditableCelleTagMultiSelect(DESIGN-SYSTEM.md ne definisce il comportamento, non il codice) - Mapping esatto dei campi nella migrazione
offer_services→services(price→unit_price,transformation_description→description) - Verifica/eventuale fix del JOIN
quote_items↔service_cataloginadmin-queries.ts— flag per il researcher, non bloccante - Palette colori esatta (6-8 pastello) e algoritmo hash nome→colore per i badge tag
- Posizionamento/stile esatto del divisore "inattivi"
Deferred Ideas
- Rewiring completo di
/admin/offers+OffersSectionper leggere daservices→ Phase 12 - Riuso della tabella
tags/junction polimorfica per i lead (CRM-09) → Phase 14 - Fix del JOIN
quote_items↔service_catalogse risulta rotto → bugfix separato, non Phase 11