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

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

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