docs: registra rinomina tassonomie e stato task "In revisione"

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.planning/STATE.md

@@ -3,9 +3,9 @@ gsd_state_version: 1.0
 milestone: v2.5
 milestone_name: Audit
 status: executing
-stopped_at: "v2.5 in PAUSA. In corso le modifiche hub: A e B in prod, C1 in prod, C2 (TidyCal) bloccato sulle credenziali API."
+stopped_at: "v2.5 in PAUSA. Modifiche hub: A, B, C1 e le due rifiniture del 2026-08-20 in prod; C2 (TidyCal) bloccato sulle credenziali API."
-last_updated: "2026-08-19T21:15:00.000Z"
+last_updated: "2026-08-20T15:40:00.000Z"
-last_activity: 2026-08-19 -- modifiche hub: progetti, dashboard e ingresso lead in produzione (19ed377)
+last_activity: 2026-08-20 -- modifiche hub: rinomina tassonomie e stato task "In revisione" (5547e55)
 progress:
   total_phases: 4
   completed_phases: 0
@@ -27,8 +27,8 @@ il suo progetto, senza scrivere email. · **Current focus:** modifiche hub (v2.5
 
 ## Current Position
 
-**v2.5 è in pausa per scelta** (2026-08-19): prima le modifiche all'hub chieste il
+**v2.5 è in pausa per scelta** (2026-08-19): prima le modifiche all'hub, poi il motore.
-2026-08-18, poi il motore. Phase 27 resta a metà — schema e fonti in prod, resto da scrivere.
+Phase 27 resta a metà — schema e fonti in prod, resto da scrivere.
 
 | Blocco (modifiche hub) | Stato |
 |---|---|
@@ -36,7 +36,8 @@ il suo progetto, senza scrivere email. · **Current focus:** modifiche hub (v2.5
 | B — Dashboard (inbox, linee di prodotto, timeline consegne) | ✅ in produzione 2026-08-19 |
 | C1 — `POST /api/webhooks/lead` | ✅ in produzione, provato contro il DB vero |
 | C2 — TidyCal | ⛔ **[BLOCCANTE]** vedi sotto |
-| C3 — Alleggerire l'hub | ⏸️ senza perimetro, da definire guardando i dati d'uso |
+| C3 — Alleggerire l'hub | ⏸️ senza perimetro |
+| Rifiniture — rinomina tassonomie, stato task "In revisione" | ✅ in prod 2026-08-20 |
 | D — Whop → audit | ⏸️ dipende dal motore v2.5 |
 
 Progress: [███░░░░░░░] 25% (v2.5)
@@ -71,6 +72,7 @@ Passo per passo in `STATUS.md` e in `…radiant-valley.md`.
 
 Log completo in `PROJECT.md`. Vive per il lavoro corrente:
 
+- **[2026-08-20] Rinominare una fase rinomina anche le fasi dei progetti** — non c'è FK fra tassonomia e `phases`: `importOfferIntoProject` riconosce una fase solo dal titolo (`offer_phase_id` non viene mai popolata). Senza propagazione, il re-import di un'offerta crea una fase duplicata accanto a quella vecchia. È l'unico rename che scrive fuori dal catalogo, quindi l'unico con conferma.
 - **[2026-08-19] Prima l'hub, poi il motore** — le modifiche all'hub sono indipendenti e a basso rischio, il motore no. Il Whop → audit resta ultimo perché dipende dal motore.
 - **[2026-08-19] L'incassato non attribuibile si mostra, non si spalma** — i pagamenti stanno sul progetto, non sull'offerta. Un progetto senza offerta finisce in una riga "Senza offerta" separata: spalmarlo darebbe un totale che quadra e righe che mentono.
 - **[2026-08-19] Il tempo lavorato sopravvive alla cancellazione del task** — `ON DELETE SET NULL`, mai cascade: con cascade, ripulire una fase abbasserebbe in silenzio il fatturato tracciato.

STATUS.md

@@ -1,6 +1,6 @@
 # ClientHub (IAMCAVALLI) — Status
 
-_Ultimo aggiornamento: 2026-08-19_
+_Ultimo aggiornamento: 2026-08-20_
 
 Questo è **l'unico documento narrativo** del progetto: a che punto siamo, cosa manca,
 cosa abbiamo imparato. `.planning/STATE.md` è il digest che leggono i comandi
@@ -46,6 +46,22 @@ Tre aree: dashboard, progetti, pipeline. Piano in
   regge payload piatto, `fields` annidati di Elementor e urlencoded, e non duplica chi
   compila due volte. Provato contro il DB di produzione via tunnel, poi ripulito.
 
+**In produzione dal 2026-08-20** (`3fcb10d`, `5547e55`) — due modifiche uscite dall'uso
+reale del pannello, nessuna migration (verificato: `tasks.status` è `text` senza `CHECK`):
+
+- **Rinomina di un valore di tassonomia** da `/admin/impostazioni`. Prima si poteva solo
+  aggiungere o eliminare: per cambiare nome a una fase bisognava cancellarla — il che la
+  strappava via da ogni servizio — e ricrearla a mano. `renamePoolValue` c'era già e
+  propagava ovunque tranne in un punto: `importOfferIntoProject` copia `services.fase`
+  dentro `phases.title` e poi ritrova la fase **confrontando i titoli**, perché
+  `phases.offer_phase_id` esiste in schema ma non viene mai popolata. Un rename fermo al
+  catalogo lasciava le fasi dei progetti col vecchio nome e al re-import ne nasceva una
+  duplicata. Ora propaga anche lì, con lo stesso match `trim`+`lowercase` del merge, ed
+  è l'unico rename che chiede conferma — dicendo quante fasi e quanti progetti tocca.
+- **Stato task "In revisione"**, fra "In corso" e "Fatto", visibile anche al cliente. Il
+  lavoro vero non era il nuovo stato ma i tre letterali ricopiati a mano in otto file:
+  ora tutto deriva da `TASK_STATUSES` in `src/lib/task-status.ts`.
+
 Cosa manca, e perché:
 
 - **[BLOCCANTE] TidyCal.** Non ha webhook — è scritto nella loro FAQ, la strada
@@ -167,6 +183,17 @@ cui si ricasca.
   costruire firme o hash validi in prod vanno letti da Coolify, non da `.env.local`.
 - **L'API Coolify rifiuta `is_build_time`** con 422 sul POST a
   `/api/v1/applications/<uuid>/envs`: mandare solo `key`, `value`, `is_preview`.
+- **Una lista di valori validi dimentica in silenzio, una negazione no.**
+  `recomputePhaseStatus` decideva "fase iniziata" con `status === "in_progress" ||
+  status === "done"`. Aggiungendo "In revisione", una fase con tutti i task in revisione
+  non rientrava né in `allDone` né in `anyActive` e **retrocedeva a "upcoming"**: si
+  leggeva "non iniziata" quando era quasi finita. Stesso schema in `ClientKanban`, dove
+  i task erano ripartiti da un oggetto a tre chiavi fisse invece che dalle colonne: un
+  task fuori da quelle spariva da ogni colonna e da ogni contatore, e il cliente ne
+  vedeva meno di quanti ce n'erano, **senza errore**. La causa a monte di entrambi era
+  lo stesso `as` al confine del portale, che TypeScript non verifica. Quando un insieme
+  di stati può crescere: derivare le colonne dalla costante, scrivere il predicato come
+  negazione, e normalizzare al confine invece di castare.
 - **Playwright non funziona contro `npm run dev`**: la CSP blocca `eval` e i client
   component non si idratano. Serve il build di produzione.
 - **Le API di Google cambiano forma sotto i piedi, e in silenzio.** Scrivendo