fix(conversazioni): il menu dei tag mostra una riga per persona, non per alias

Con un cliente «Gian Luca Caruso / Caruso Speaker» il menu proponeva tre voci
per un destinatario solo. Non era un difetto di resa: al menu era stata passata
la stessa lista che il parser usa per RICONOSCERE un tag rileggendo il testo.

Sono due domande diverse, e il codice le aveva confuse:
  - come lo si puo' scrivere -> tutti gli alias, invisibili, solo in lettura
  - chi si puo' scegliere    -> una riga per destinatario

`MentionTarget` le separa: `label` per il menu, `aliases` per la rilettura.
Scrivere «@Gian» a mano continua a valere come tag e a far partire la mail --
cambia solo cosa viene offerto, non cosa viene accettato.

Il filtro del menu ora passa da `normalizeForSearch`, la stessa
normalizzazione del parser: con un toLowerCase() a parte, digitare «nicolo»
non avrebbe trovato «Nicolò» nel menu mentre nel messaggio sarebbe stato
riconosciuto -- due regole per la stessa domanda, e la seconda si scopre solo
quando la mail non parte.

Il difetto scalava peggio del valore: con tre contatti per cliente sarebbero
diventate nove righe. `mentionTargets()` ritorna gia' un array per questo, ma
il tag per singola persona resta impossibile finche' `client_emails` ha gli
indirizzi e non i nomi: serve una migration, ed e' un lavoro a se'.

Verificato: build e lint puliti, 23 test su parser e menu. Mai visto a schermo.

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

.claude/CLAUDE.md

@@ -0,0 +1,77 @@
+# `.claude/` — la cartella di configurazione di ClientHub
+
+Questo file si carica quando si lavora **dentro `.claude/`**. Spiega cosa va dove, e basta.
+
+**Per il progetto comanda [`../CLAUDE.md`](../CLAUDE.md)**: stack, vincoli LOCKED, procedura
+di deploy, accesso al DB, design system. Qui non si duplica niente di quello — una seconda
+copia è il modo più veloce per averne due che si contraddicono.
+
+## Cosa va in ogni cartella
+
+| Cartella | Cosa ci va | Cosa **non** ci va |
+|---|---|---|
+| `rules/` | Regole caricate per contesto. Oggi: `memory-discipline.md`, importata da `../CLAUDE.md` | Documentazione di feature — quella sta in `STATUS.md` |
+| `skills/` | **Solo** skill specifiche di ClientHub: `preventivo/`, `audit/` | Le skill globali (`/seo-audit`, `/copywriting`, `/docx`…) — stanno in `~/.claude/skills/` |
+| `agents/` | **Solo** agenti specifici di ClientHub. Oggi vuota: quello dell'audit nasce col motore | I 18 agenti globali di `~/.claude/agents/` |
+| `hooks/` | Script eseguibili richiamati da `settings.json` | Logica di prodotto |
+| `plans/` | I piani delle milestone, versionati | Piani usa-e-getta di una singola sessione |
+| `commands/`, `workflows/`, `projects/` | Vuote per ora, sono lo scheletro | — |
+| `memory/` | Appunti di lavoro versionati nel repo | **La memoria persistente. Non è qui** → vedi sotto |
+| `worktrees/` | Generata dagli strumenti | — |
+
+### Agenti e skill globali non si copiano qui
+
+Regola già fissata in [`../../CLAUDE.md`](../../CLAUDE.md): agenti e skill che valgono per
+tutti i progetti vivono in `~/.claude/` e si invocano da qualunque cartella. Copiarne uno qui
+crea due file destinati a divergere, e il primo a cambiare vince a caso.
+
+In locale ci va solo ciò che **senza questo repo non ha senso**: le due skill qui sotto.
+
+### `.claude/memory/` ≠ memoria persistente
+
+Due posti diversi con lo stesso nome, e confonderli fa perdere il lavoro:
+
+- **`.claude/memory/`** (questa cartella) — appunti versionati nel repo, li vede chiunque
+  faccia clone.
+- **`~/.claude/projects/-Users-simonecavalli-Vault-IAMCAVALLI-hub/memory/`** — la memoria
+  persistente vera, un file per fatto più `MEMORY.md` come indice. Sta fuori dal repo, non
+  si committa, e viene iniettata in automatico a inizio sessione.
+
+Ci va quello che **non si deduce dal repo**: perché una decisione è stata presa, un vincolo
+operativo, una cosa provata che non funziona. Regole complete in
+[`rules/memory-discipline.md`](rules/memory-discipline.md).
+
+## Le skill del progetto
+
+- **`/preventivo`** — l'attrezzo per lavorare sulla pipeline che genera i preventivi
+  (`src/lib/proposal/`) senza romperla. Non contiene un prompt di generazione: quello vive
+  in `agent.ts` ed è l'unico.
+- **`/audit`** — fa girare le cinque fonti di `src/lib/audit/sources/` su un URL e dice cosa
+  è stato **misurato** e cosa no. Le fonti sono in produzione ma inerti: nessuna route le
+  chiama ancora.
+
+## Gli hook attivi
+
+Tutti e tre in [`settings.json`](settings.json). Si provano a mano prima di fidarsi.
+
+| Hook | Quando | Cosa fa |
+|---|---|---|
+| Promemoria memoria | `Stop` | Se `src/` o `.planning/` hanno modifiche non committate, ricorda di aggiornare `STATE.md`. Non blocca |
+| [`guardia-migration.sh`](hooks/guardia-migration.sh) | `PreToolUse` su Write/Edit in `src/db/migrations/` | **Blocca** l'SQL che cancella dati dalle entità protette (`clients`, `projects`, `payments`, `phases`). È il vincolo Data Safety LOCKED fatto rispettare dalla macchina |
+| [`guardia-token.sh`](hooks/guardia-token.sh) | `PostToolUse` su `.tsx`/`.css` | **Avvisa** se compaiono classi Tailwind grezze o hex letterali. Non blocca: le eccezioni sanzionate esistono e stanno nella whitelist dello script |
+
+Per provarli senza passare da Claude:
+
+```bash
+echo '{"tool_input":{"file_path":"src/db/migrations/9999_x.sql","content":"DROP TABLE payments;"}}' \
+  | .claude/hooks/guardia-migration.sh; echo "exit=$?"   # atteso: 2
+
+echo '{"tool_input":{"file_path":"src/x.tsx","content":"<div className=\"bg-slate-100\"/>"}}' \
+  | .claude/hooks/guardia-token.sh; echo "exit=$?"       # atteso: 0 + avviso
+```
+
+## I piani
+
+`plans/` contiene i piani della milestone v2.5, portati dentro il repo il 2026-08-26 perché
+stavano solo in `~/.claude/plans/` e `STATE.md` avvertiva che senza quelli la milestone non
+era ricostruibile. Dettaglio in [`plans/README.md`](plans/README.md).

.claude/hooks/guardia-migration.sh

@@ -0,0 +1,61 @@
+#!/usr/bin/env bash
+# PreToolUse su Write/Edit — vincolo Data Safety (LOCKED) di ../../CLAUDE.md.
+#
+# Blocca la scrittura di una migration che cancella dati dalle entita' protette.
+# Non e' una prova: e' una rete. Un DROP scritto in modo esotico puo' passare —
+# la revisione a occhio dell'SQL resta obbligatoria.
+#
+# exit 0 = passa · exit 2 = bloccato, il messaggio su stderr torna a Claude.
+set -uo pipefail
+
+INPUT=$(cat)
+FILE=$(printf '%s' "$INPUT" | jq -r '.tool_input.file_path // empty')
+
+# Fuori da src/db/migrations/ questo hook non ha voce in capitolo.
+case "$FILE" in
+  *src/db/migrations/*) ;;
+  *) exit 0 ;;
+esac
+
+# Write porta `content`, Edit porta `new_string`. MultiEdit porta un array.
+SQL=$(printf '%s' "$INPUT" | jq -r '
+  [ .tool_input.content?,
+    .tool_input.new_string?,
+    (.tool_input.edits? // [] | .[].new_string?)
+  ] | map(select(. != null)) | join("\n")
+')
+[ -z "$SQL" ] && exit 0
+
+PROTETTE='clients|projects|payments|phases'
+
+# Via i commenti, tutto minuscolo, una riga per statement: cosi' "DROP" e il nome
+# della tabella devono stare nella STESSA istruzione per far scattare il blocco.
+PULITO=$(printf '%s' "$SQL" \
+  | sed -E 's/--.*$//' \
+  | tr '\n' ' ' \
+  | sed -E 's;/\*[^*]*\*+([^/*][^*]*\*+)*/; ;g' \
+  | tr '[:upper:]' '[:lower:]' \
+  | tr ';' '\n')
+
+COLPEVOLI=$(printf '%s\n' "$PULITO" \
+  | grep -E 'drop[[:space:]]+table|drop[[:space:]]+column|truncate|delete[[:space:]]+from' \
+  | grep -E "\\b($PROTETTE)\\b" || true)
+
+if [ -n "$COLPEVOLI" ]; then
+  {
+    echo "BLOCCATO — Data Safety (LOCKED, ../CLAUDE.md)."
+    echo
+    echo "Questa migration cancella dati da un'entita' protetta (clients, projects,"
+    echo "payments, phases). Le migration sono additive: si aggiungono colonne e"
+    echo "tabelle, non si tolgono righe."
+    echo
+    echo "Istruzioni incriminate:"
+    printf '%s\n' "$COLPEVOLI" | sed 's/^[[:space:]]*/  · /'
+    echo
+    echo "Se la rimozione serve davvero, e' una decisione da confermare a voce con"
+    echo "l'utente prima di scriverla — non da aggirare qui."
+  } >&2
+  exit 2
+fi
+
+exit 0

.claude/hooks/guardia-token.sh

@@ -0,0 +1,59 @@
+#!/usr/bin/env bash
+# PostToolUse su .tsx/.css — regola cardinale del design system:
+# solo token semantici (bg-card, text-muted-foreground, border-border).
+#
+# AVVISA, non blocca: le eccezioni sanzionate esistono (vedi WHITELIST) e il
+# debito storico e' gia' di ~450 occorrenze. Bloccare renderebbe l'hook un
+# ostacolo da disattivare invece di un promemoria da leggere.
+#
+# exit 0 sempre. Il messaggio su stderr arriva a Claude come contesto.
+set -uo pipefail
+
+INPUT=$(cat)
+FILE=$(printf '%s' "$INPUT" | jq -r '.tool_input.file_path // empty')
+
+case "$FILE" in
+  *.tsx|*.css) ;;
+  *) exit 0 ;;
+esac
+
+# Eccezioni sanzionate da ../CLAUDE.md § Design System:
+#  - StatusBadge: i colori di stato usano la palette con variante dark: esplicita
+#  - AdminShell: il verde brand della sidebar
+#  - mailer.ts / .html: l'HTML delle email non puo' usare variabili CSS
+#  - globals.css: e' il posto dove i token vengono *definiti*
+#  - design-reference/: i mock precedono la regola, si traducono non si copiano
+case "$FILE" in
+  *StatusBadge*|*AdminShell*|*mailer*|*globals.css|*design-reference/*) exit 0 ;;
+esac
+
+TESTO=$(printf '%s' "$INPUT" | jq -r '
+  [ .tool_input.content?,
+    .tool_input.new_string?,
+    (.tool_input.edits? // [] | .[].new_string?)
+  ] | map(select(. != null)) | join("\n")
+')
+[ -z "$TESTO" ] && exit 0
+
+PALETTE='slate|gray|zinc|neutral|stone|red|orange|amber|yellow|lime|green|emerald|teal|cyan|sky|blue|indigo|violet|purple|fuchsia|pink|rose'
+GREZZE=$(printf '%s\n' "$TESTO" \
+  | grep -oE "\\b(bg|text|border|ring|from|to|via|fill|stroke|divide|outline|shadow|accent|decoration|placeholder)-($PALETTE)-[0-9]{2,3}\\b" \
+  | sort -u | head -12 || true)
+HEX=$(printf '%s\n' "$TESTO" \
+  | grep -oE '#[0-9a-fA-F]{3,8}\b' | sort -u | head -6 || true)
+
+if [ -n "$GREZZE" ] || [ -n "$HEX" ]; then
+  {
+    echo "AVVISO design system — token semantici, non palette grezza."
+    echo "File: $FILE"
+    [ -n "$GREZZE" ] && { echo "  classi grezze: $(printf '%s ' $GREZZE)"; }
+    [ -n "$HEX" ]    && { echo "  hex letterali: $(printf '%s ' $HEX)"; }
+    echo
+    echo "Usa bg-card / text-muted-foreground / border-border: e' quello che fa"
+    echo "funzionare chiaro e scuro sul solo toggle della classe .dark."
+    echo "Riferimento: design-reference/DESIGN-SYSTEM.md"
+    echo "Eccezione sanzionata? Aggiungi il file alla WHITELIST di questo hook."
+  } >&2
+fi
+
+exit 0

.claude/plans/README.md

@@ -0,0 +1,17 @@
+# Piani
+
+I piani delle milestone, **dentro il repo**. Ci sono arrivati il 2026-08-26: prima
+stavano solo in `~/.claude/plans/`, con nomi generati a caso, e `STATE.md` avvertiva
+che senza quei file v2.5 non era ricostruibile. Un piano che vive solo sul portatile
+di chi l'ha scritto non e' documentazione, e' un ricordo.
+
+| File | Cosa contiene | Origine |
+|---|---|---|
+| `v2.5-audit-documento.md` | Il documento di audit: tre livelli (Radiografia / Prima-Dopo / Rotta) come configurazioni di un unico documento su `/audit/[slug]` | `dovremmo-fare-una-cosa-woolly-puddle.md` |
+| `v2.5-audit-motore.md` | Il motore: raccolta in parallelo, quattro sub-agent, sintetizzatore. Il vincolo che regge tutto — **un numero entra solo se misurato** | `vorrei-solo-farti-capire-radiant-valley.md` |
+| `v2.5-modifiche-hub.md` | I blocchi A/B/C delle modifiche all'hub chieste il 2026-08-18 | `sei-arrivato-qua-search-recursive-kettle.md` |
+
+Sono **piani, non stato**: dicono cosa era stato deciso di fare, non cosa e' fatto.
+Per quello ci sono `STATUS.md` (narrativa) e `.planning/STATE.md` (digest).
+Passati al setaccio per credenziali prima del commit: dentro compaiono nomi di
+variabili d'ambiente, mai i loro valori.

.claude/plans/v2.5-audit-documento.md

@@ -0,0 +1,413 @@
+# Audit — documento di restituzione
+
+## Context
+
+iamcavalli vende un servizio di analisi sito in tre livelli (La Radiografia / Il Prima-Dopo / La Rotta). Il deliverable è un documento di restituzione presentato in una call da 40 minuti. Oggi si fa a mano fuori dall'hub.
+
+Il servizio si chiama **audit** → rotta `/audit/[slug]`. Il nome del livello acquistato compare **solo in copertina**.
+
+```
+acquisto Whop ──┐
+                ├─► audit creato ─► intake dati ─► agent: analisi profonda
+creazione manuale ┘                                         │
+                                                            ▼
+     call (fissata a mano) ◄── consegna ◄── revisione + redesign (manuale)
+```
+
+Il redesign lo prepari tu mentre gli agent lavorano. **Deve essere possibile creare un cliente e far partire l'audit in manuale, senza acquisto.**
+
+Volume: ~50 audit/anno. Overhead non-analitico sotto i 10 minuti per audit. Regola guida: *tu scrivi solo analisi e redesign, tutto il resto si popola*.
+
+### Documento canonico
+
+La **Spec V1** (blocchi, copy fisso, campi) è il documento canonico. L'Excel *Ecommerce Growthlist* è **rubrica interna del motore di analisi**, non struttura del documento — vedi §4.
+
+### Verdetto di fattibilità
+
+Fattibile. Tre pezzi da costruire da zero: **motore di analisi**, **PDF**, **hosting immagini**. Il resto ha precedenti diretti in casa.
+
+### Conflitti risolti a favore del progetto
+
+| Spec V1 | Qui | Perché |
+|---|---|---|
+| Supabase | Neon + Drizzle | Lo stack è quello |
+| `uuid` | `text` + `nanoid()` | Convenzione di tutte le tabelle in `schema.ts` |
+| PDF serverless headless | Print CSS | Deploy Docker su Coolify, non serverless. Stesso risultato, zero infra |
+| `/r/[slug]?k=[token]`, slug = nome cliente | `/audit/[slug]`, slug nanoid nel path | **Sicurezza** (sotto) |
+
+**Sullo slug.** `teckell-2026` è indovinabile: la segretezza si sposterebbe tutta sul token in query string, e i parametri di query finiscono nei log d'accesso e nei referrer molto più facilmente di un path. Il `Referrer-Policy: strict-origin-when-cross-origin` già presente mitiga in parte, ma la convenzione collaudata qui è **nanoid non indovinabile nel path, niente query** (`/preventivo/[slug]`, `/quote/[token]`). Un audit nomina un'azienda reale e ne elenca le debolezze: è il contenuto più sensibile che il portale pubblicherà.
+
+**Due correzioni ad altre premesse:**
+
+1. **I `gsd-audit-*` non c'entrano.** Verificato: `gsd-audit-milestone` verifica una milestone GSD, `gsd-audit-uat` raccoglie i test in sospeso, `gsd-audit-fix` sistema i finding nel *tuo* codebase. Auditano il progetto, non il sito del cliente. Motore custom; il precedente è `src/lib/proposal/agent.ts`.
+2. **Il deck dei preventivi non è riusabile come layout.** `ProposalDeck.tsx:151` monta solo la slide corrente e `:133` imposta `body.overflow = "hidden"`: stamparlo produce una pagina sola. Il documento è **a scorrimento**. Si riusa schema e macchina a stati, non il guscio visivo.
+
+### Decisioni prese
+
+| Punto | Decisione |
+|---|---|
+| Motore | In-app, background, polling dall'admin (§5) |
+| "La direzione" (blocco 8) | Manuale, foglio bianco, **con il materiale grezzo a fianco** |
+| PDF | Print CSS — stesso DOM, vincolo "una sola fonte" per costruzione |
+| Immagini | Volume persistente. **Modifica il vincolo LOCKED #5** (§9) |
+| Redesign | Immagini caricate **e** link Figma, con ruoli distinti (§6) |
+| Miglioramento nel tempo | Template versionato: tocca gli audit futuri, mai i consegnati (§3) |
+| Copertina | Titolo = nome del livello acquistato |
+| Scadenza | Nessuna. Depubblicazione manuale reversibile |
+| Tracking | Prima apertura, ultima apertura, conteggio |
+
+---
+
+## 1 · Spike sul motore — si parte da qui
+
+È la parte più incerta e quella su cui si regge tutto il resto. Se la qualità dell'analisi non regge, meglio scoprirlo prima di costruirci sopra schema, editor e documento.
+
+**Non tocca il database, non tocca l'hub.** Uno script isolato, `scripts/spike-audit.ts`, sul sito di un cliente attuale, che stampa l'output grezzo.
+
+Deve dimostrare che:
+- Il fetch delle pagine chiave e l'estrazione del testo reggono su un sito reale
+- La verifica delle voci di checklist è **affidabile e ripetibile** (§4)
+- I problemi sono **concreti, non generici** — "il messaggio non è chiaro" non vale niente, "l'headline non nomina il destinatario" sì
+- La conseguenza per il business è specifica
+
+Da riusare subito: la protezione da prompt injection di `src/lib/proposal/agent.ts:32-35` (blocco SICUREZZA che dichiara il contenuto come dati, non istruzioni) e `:49` (neutralizzazione dei tag di chiusura). Con HTML scrapato da un sito esterno serve **più** che con le trascrizioni: è contenuto di terzi e può contenere istruzioni ostili.
+
+> Il resto si esegue **dopo** esito positivo dello spike.
+
+---
+
+## 2 · Il documento
+
+Un solo documento ben progettato; i tre livelli sono **configurazioni** di quello.
+
+| # | Blocco | Radiografia | Prima/Dopo | Rotta |
+|---|---|:--:|:--:|:--:|
+| 1 | Copertina | ● | ● | ● |
+| 2 | Sintesi | ● | ● | ● |
+| 2b | **Cosa funziona già** | ● | ● | ● |
+| 3 | Stato di fatto | ● | ● | ● |
+| 4 | I problemi, per impatto | ● | ● | ● |
+| 5 | Analisi per area | ● | ● | ● |
+| 6 | Il redesign | — | ● | ● |
+| 6b | **Cosa il redesign non risolve** | — | ● | ● |
+| 7 | Le ottimizzazioni | — | — | ● |
+| 8 | La direzione | ● | ● | ● |
+| 9 | Come si prosegue | ● | ● | ● |
+
+I blocchi non pertinenti **non esistono nel DOM**, non sono nascosti via CSS.
+
+Il **copy fisso** di ogni blocco è quello della Spec V1, riportato integralmente in `template/v1.ts` (§3). Nel blocco 9 le *fasi già completate* si derivano dal livello acquistato, e il credito riconosciuto è `importo_pagato`.
+
+**I due blocchi 2b e 6b sono aggiunte del prototipo Giojello, non della Spec V1**, e vanno tenute:
+- *Cosa funziona già* costruisce credibilità prima di criticare, e dichiara cosa non va toccato
+- *Cosa il redesign non risolve* è onesto e commercialmente più efficace della vendita: apre al progetto completo senza promettere
+
+Campi: `punti_forza` (lista) e `redesign_limiti` (testo).
+
+### Il prototipo Giojello è il riferimento del template v1
+
+Il file HTML prodotto per Giojello **non è il documento: è la fonte di `template/v1.ts`** — copy, tipografia, gerarchia. Va spacchettato in componenti alimentati dal record. Quattro difetti da NON portarsi dietro:
+
+1. **Contenuto cablato nel markup** (699€, 8,0s, 500€, le date). Viola il vincolo "un record → una pagina → un PDF": tutto viene dal DB
+2. **Google Fonts via `<link>`** — la CSP del progetto è `font-src 'self' data:` e `style-src 'self' 'unsafe-inline'`: verrebbe **bloccato** e il documento cadrebbe sui font di sistema. **Font self-hostati** (Instrument Serif / Inter / IBM Plex Mono, se si conferma quel trio in luogo di Plus Jakarta Sans — è una deroga consapevole a DESIGN-SYSTEM.md, giustificabile perché è un documento pubblico, non la UI admin)
+3. **Print CSS di sei righe.** Nasconde la legenda interna ma **non i colori che la legenda spiega**: i bordi e i testi rossi/blu dei blocchi di lavorazione finiscono stampati senza più nulla che li spieghi. I marcatori di lavorazione non devono esistere nel documento consegnato
+4. **Colore come unico portatore di informazione nelle metriche** — `3,4 s` rosso e `1,0 s` verde diventano identici in scala di grigi. Serve un secondo canale (glifo, peso, etichetta)
+
+⚠️ **Tassonomia degli impatti.** Il prototipo usa cinque valori ("medio-alto", "basso-medio"…), lo schema ne prevede tre. Con cinque l'ordinamento automatico su tre non funziona. Decisione: si resta a **tre valori**, e la sfumatura sta nell'ordine dentro il gruppo (`sort_order`).
+
+### Regola di collocazione: finding vs analisi
+
+Il prototipo v2 ha aggiunto una sezione discorsiva "Interfaccia" con otto paragrafi che contengono almeno quattro **veri finding** — contrasto insufficiente sulla CTA della hero, riflesso che mangia il 40% dell'immagine prodotto, titoli troncati, e soprattutto il carrello (spedizione assicurata 39,90€ contro 6,13€ con la non assicurata preselezionata). Quest'ultimo è da primi cinque ed era in coda a una sezione discorsiva.
+
+**Regola per il motore e per l'editor:** se una cosa ha un impatto e una conseguenza, è un finding — va nel blocco 4, prende un numero e viene ordinata. Il blocco 5 resta discorsivo e resta a **tre aree** (struttura / messaggio / conversione). Nessuna quarta area.
+
+Motivo: il documento promette "non un elenco di quaranta punti", e una seconda lista non ordinata dopo quella ordinata annulla la promessa. La forza del documento è la **selezione**.
+
+### Disciplina sui numeri — vincolo del motore
+
+Confronto con un audit parallelo dello stesso sito prodotto da un altro modello: conteneva "~65% abbandono stimato" e "+60% velocità mobile immediata". **Nessuno dei due è misurato**: sono congetture presentate come rilevazioni.
+
+Il prototipo Claude è disciplinato su questo — dice "una parte importante del traffico" proprio perché non può quantificarla. **Quella disciplina va imposta nel prompt di sistema del motore**: un numero compare nel documento solo se proviene da una rilevazione (PageSpeed, conteggio DOM, peso pagina, dati del sito). Mai stime di conversione o di guadagno percentuale. In un deliverable premium basta un cliente che verifichi per bruciare tutta la credibilità.
+
+Voce di verifica: nessun numero nel documento consegnato è privo di fonte in `audit_runs.raw`.
+
+### Contributi da assorbire dall'audit parallelo
+
+- **La misura/taglia nella griglia prodotti** — su pezzi unici rigenerati è criterio di scelta primario e non compare da nessuna parte. Si aggancia al finding sull'unicità e apre a un servizio ("messa a misura disponibile"). Va nella checklist profilo `ecommerce` come voce
+- **Conteggio dei nodi DOM** — quantifica il problema di peso meglio dei MB. Da aggiungere alle rilevazioni di `fetch.ts`
+- **Stime in giornate** — alimentano la colonna *Impegno* del blocco 7
+
+### Estensione opzionale — allegato tecnico (NON in fase 1)
+
+Il blocco 9 promette *"il documento resta tuo e puoi darlo a chiunque lavorerà sul sito"*, ma consegna prosa da imprenditore a uno sviluppatore.
+
+Un **allegato tecnico generato dallo stesso record** — stessi finding, registro da sviluppatore, con selettori, file coinvolti e stime — renderebbe quella promessa molto più preziosa. È una seconda vista sugli stessi dati, quindi non viola il vincolo della fonte unica e non richiede contenuto aggiuntivo. Da valutare dopo il primo audit consegnato.
+
+---
+
+## 3 · Versionamento del template
+
+Requisito: migliorare il documento deve toccare gli audit **successivi**, mai quelli già consegnati.
+
+Precedente in casa: `proposals.content` congela profilo e prezzi alla generazione, così modificarli dopo non retro-cambia un preventivo pubblicato.
+
+Copy fisso e configurazione dei blocchi vivono in **moduli TS versionati**, non nel database:
+
+```
+src/lib/audit/template/
+  v1.ts      copy fisso di ogni blocco + ordine + mappa livello→blocchi
+  index.ts   registry versione→modulo + LATEST_TEMPLATE_VERSION
+```
+
+- `audits.template_version` impostata alla versione corrente **alla creazione**
+- Un audit **consegnato resta congelato** sulla sua versione, per sempre
+- Migliorare il documento = aggiungere `v2.ts` e alzare `LATEST_TEMPLATE_VERSION`. Nessuna migration, nessun backfill, storia completa in git
+- Le **bozze** si portano all'ultima versione con un bottone esplicito, mai in automatico
+
+---
+
+## 4 · La checklist come rubrica del motore
+
+L'Excel ha 264 voci su 7 step di funnel, con scoring ICE e peso di importanza per sezione. Serve al **motore**, non al documento.
+
+**Perché è preziosa:** ogni voce è un'asserzione binaria e verificabile ("Il checkout consente l'acquisto come ospite"). Verificare 264 affermazioni falsificabili è molto più affidabile che chiedere a un modello "analizza questo sito": trasforma l'analisi da generativa a **verificativa**, controllabile voce per voce. E lo scoring ICE risolve gratis l'ordinamento del blocco 4 e le priorità del blocco 7.
+
+**Tre vincoli emersi dalla lettura del file:**
+
+1. **È al 73% ecommerce.** Generale (50) e Homepage (21) valgono per qualsiasi sito; Categoria, Scheda Prodotto, Carrello, Checkout, Ringraziamento — **193 voci su 264** — presuppongono un carrello. Servono **due profili**: `ecommerce` e `servizi`. Il secondo va scritto, non esiste nel file.
+2. **Misura la conformità, non l'adeguatezza.** Un sito può fare 250/264 e continuare a descrivere un'azienda che non esiste più. Nessuna voce chiede se il posizionamento dichiarato corrisponde a quello che vendi oggi, o se le prove sono della fascia di cliente giusta. La checklist è il **pavimento** (guasti meccanici, li trova l'agent); lo scarto strategico è il **soffitto** e resta analisi tua. Se il documento diventa il rendering della checklist, torna a sembrare un audit automatico gratuito.
+3. **Molte voci sono tattiche da ecommerce a volume** — scarsità, urgenza, countdown, popup di social proof. Su un brand premium **danneggiano**: abbassano il segnale di prezzo mentre tu vendi il contrario. Ogni voce porta quindi un campo `registro` (`volume` / `premium` / `neutro`) e l'audit di un brand premium non propone mai i trigger da discount.
+
+⚠️ Note tecniche sul file: il foglio *Algoritmo* ha errori **`#REF!`**, e la colonna *Facilità* è **1.0 su tutte le righe** — non compilata, quindi lo Score attuale è di fatto solo Impatto × Confidenza. Da sistemare prima di seminarne i default.
+
+Il foglio *Best Ecommerce List* (88 siti per settore) alimenta confronti concreti: "il tuo checkout chiede 11 campi, i riferimenti del settore ne chiedono 6".
+
+**Nel documento** la checklist non compare come elenco. Il blocco 3 mostra al massimo il grado di conformità **per step di funnel** (una barra per step), accanto alle metriche di performance. I problemi del blocco 4 sono una **selezione curata** — voci non conformi ad alto impatto più lo scarto strategico — non il dump delle non conformità.
+
+---
+
+## 5 · Migration `0017_audits.sql`
+
+Additiva e idempotente. Template di stile: `src/db/migrations/0016_retainer_lifecycle.sql` (header in italiano che spiega il *perché*, `ADD COLUMN IF NOT EXISTS`, `CHECK ... NOT VALID` dentro `DO $$ ... pg_constraint`, `CREATE INDEX IF NOT EXISTS`).
+
+Convenzioni da `src/db/schema.ts`: id `text` con `$defaultFn(() => nanoid())`, **nessun `pgEnum`** (text + CHECK in SQL + tupla `as const` in TS + Zod nell'action), timestamp `withTimezone: true`, `updated_at` bumpato a mano nell'action.
+
+**`audits`** — colonne scalari, non jsonb: non c'è snapshot da congelare (ci pensa `template_version`) e l'editor mappa 1:1.
+
+- Identità: `id`, `slug` unique nanoid, `lead_id` → `leads` SET NULL, `client_id` → `clients` SET NULL (nullable entrambi, come `proposals`)
+- Config: `livello` CHECK `('radiografia','prima_dopo','rotta')`, `template_version`, `profilo` CHECK `('ecommerce','servizi')`, `cliente_nome`, `cliente_referente`, `sito_url`, `importo_pagato numeric(10,2)`, `data_consegna date`
+- Origine: `origin` CHECK `('manuale','whop')` default `'manuale'`, `external_ref` — predispone Whop senza costruirlo
+- Stato: `state` CHECK `('draft','published')` default `'draft'` (etichettati *Bozza* / *Consegnata* nella UI), `published_at`
+- Tracking: `first_viewed_at`, `last_viewed_at`, `view_count integer default 0`
+- Rilevazioni (blocco 3): `perf_mobile`, `perf_desktop`, `lcp numeric(6,2)`, `cls numeric(5,3)`, `inp`, `pagine_indicizzate`, `screenshot_desktop_url`, `screenshot_mobile_url`, `measured_at`
+- Contenuto (blocchi 2/2b/5/8): `sintesi`, `punti_forza jsonb` (lista, blocco 2b), `analisi_struttura`, `analisi_messaggio`, `analisi_conversione`, `direzione`
+- Redesign (blocchi 6/6b): `redesign_sezione`, `redesign_prima_url`, `redesign_dopo_url`, `redesign_razionale`, `redesign_limiti`, `redesign_figma_url`
+- Intake: `intake jsonb` — i dati che il cliente condivide, forma ancora da definire
+
+**Tutti i campi di contenuto sono nullable.** È ciò che rende possibile "si salva sempre, anche a metà": la validazione di completezza scatta solo alla consegna.
+
+**`audit_findings`** (blocco 4) — `audit_id` CASCADE, `titolo`, `impatto` CHECK `('alto','medio','basso')`, `area` CHECK `('struttura','messaggio','conversione','performance')`, `descrizione`, `conseguenza`, `screenshot_url`, `sort_order integer default 0`, `origin` CHECK `('agent','manuale')`
+
+**`audit_optimizations`** (blocco 7) — `audit_id` CASCADE, `intervento`, `priorita` CHECK `('alta','media','bassa')`, `motivazione`, `impegno`, `sort_order integer default 0`
+
+**`checklist_items`** (rubrica, versionata come il template) — `profilo`, `step`, `focus`, `testo`, `impatto_default`, `confidenza_default`, `registro` CHECK `('volume','premium','neutro')`, `sort_order`
+
+**`audit_checklist_results`** — `audit_id` CASCADE, `item_id`, `esito` CHECK `('conforme','non_conforme','non_rilevante')`, `note`, `evidenza`, `origin` CHECK `('agent','manuale')`
+
+**`audit_runs`** (§6) — `audit_id` CASCADE, `status` CHECK `('queued','running','done','error')`, `step`, `started_at`, `finished_at`, `heartbeat_at`, `error`, `raw jsonb` (output grezzo: materiale per il blocco 8)
+
+Indici: unique su `slug`; index su `client_id`, `lead_id`, `(audit_id, sort_order)` per le figlie, `(audit_id, started_at desc)` per le run, `(audit_id, item_id)` unique per i risultati.
+
+**Ordinamento automatico** (blocchi 4 e 7): la query ordina per rango di impatto/priorità con `sort_order` come spareggio *dentro* il gruppo. Tu non ordini niente.
+
+> ⚠️ **Checkpoint bloccante.** Migration applicata in produzione **prima** di pushare il codice schema-dipendente (regola CLAUDE.md "Ordering"), via SSH/docker-exec. Aggiornare `src/db/schema.ts` a mano in parallelo — `drizzle-kit generate` è rotto.
+
+---
+
+## 6 · Motore di analisi
+
+`src/lib/audit/` modellato su `src/lib/proposal/` ma multi-step:
+
+```
+src/lib/audit/
+  pipeline.ts   funzione pura: (auditId) => risultato. Non conosce chi la chiama
+  agent.ts      chiamate Anthropic, una per step di funnel
+  schema.ts     validazione Zod dell'output
+  fetch.ts      recupero pagine + estrazione testo + PageSpeed
+```
+
+**Passi:** recupero pagine chiave → metriche PageSpeed → verifica delle voci di checklist del profilo → sintesi dei problemi con impatto+area+descrizione+conseguenza.
+
+Tutto l'output è **bozza**: finisce in `audit_checklist_results` e in `audit_findings` con `origin='agent'`. Tu rivedi e correggi prima di consegnare. Si automatizza il meccanico, **il giudizio resta tuo**.
+
+**Il blocco 8 "La direzione" resta manuale, foglio bianco.** L'editor mostra a lato il materiale grezzo — problemi ad alto impatto e temi ricorrenti, da `audit_runs.raw`. Nessun testo proposto, nessun template. È il blocco che giustifica il prezzo: se diventa formula, il cliente lo sente.
+
+**Esecuzione: in-app, background, con polling.**
+- "Avvia analisi" → riga `audit_runs` con `status='queued'`, lancia la pipeline
+- L'admin fa polling e mostra `step` corrente e avanzamento
+- Progresso scritto a ogni passo: un'interruzione non perde il lavoro fatto
+
+> ⚠️ **Rischio da mettere in conto.** Con `output: "standalone"` su singolo container Coolify, un redeploy **uccide un job in corso** e lascia una riga bloccata su `running`. Mitigazione: `heartbeat_at` aggiornato a ogni passo, le run senza heartbeat da N minuti vanno in `error`, e "Rilancia" riparte dall'ultimo passo completato. Non è un sistema a code: è deliberatamente il minimo che regge 50 audit/anno.
+
+`pipeline.ts` è una **funzione pura riusabile**: oggi la chiama il bottone, domani il webhook Whop. Nessuna riscrittura.
+
+---
+
+## 7 · Storage immagini e redesign
+
+Servono: 2 screenshot home, N screenshot dei problemi, 2 immagini redesign. Con URL esterni incollati a mano il budget dei 10 minuti non regge, e un URL morto uccide il documento del cliente.
+
+**Volume persistente, non servizio esterno.** Nessuna dipendenza npm nuova, nessun account terzo, nessuna credenziale.
+
+- Volume Coolify montato su `/app/uploads`
+- Upload via **server action** che riceve `File` da `FormData`. Niente upload diretto dal browser: la CSP ha `connect-src 'self'`, un POST verso un host esterno sarebbe bloccato — passare dal nostro origin è l'unica strada e va bene così
+- Validazione: whitelist MIME `image/png|jpeg|webp`, max 5MB, nome file `nanoid()` (mai l'originale)
+- Lettura via `src/app/api/uploads/[...path]/route.ts` con guardia sul path traversal e `Cache-Control` lungo
+- CSP invariata: serviamo dal nostro origin, coperto da `img-src 'self'`
+
+> ⚠️ **Checkpoint bloccante.** Volume creato in Coolify prima del deploy, altrimenti gli upload si perdono a ogni redeploy.
+
+Nuovo componente `ImageUploadField` — in tutto `src/` non c'è un solo `<input type="file">`.
+
+**Il redesign usa entrambi i formati, con ruoli distinti:**
+- **Immagini caricate** — rappresentazione canonica, quelle che si vedono nello slider e **le uniche che finiscono nel PDF**
+- **Link Figma** — opzionale, "apri il redesign interattivo", nuova scheda
+
+Perché non embeddare Figma: la CSP ha `default-src 'self'` senza `frame-src`, quindi l'iframe sarebbe bloccato; e un iframe **in stampa non produce nulla**, rompendo il vincolo "una sola fonte" proprio sul blocco che vale di più.
+
+---
+
+## 8 · Pagina pubblica e PDF
+
+`/audit/[slug]`, modellata su `src/app/preventivo/[slug]/page.tsx`: `export const revalidate = 0`, fetch by slug, `notFound()` se assente.
+
+**Differenze deliberate dal preventivo:**
+- **Documento a scorrimento.** Nessun `h-screen`, nessun `overflow-hidden`, nessuna manipolazione di `body.style`
+- **Rate limit**: aggiungere `/audit` al matcher di `src/proxy.ts` riusando `src/lib/rate-limit.ts`. Il preventivo non ce l'ha — non ereditare quell'omissione
+- **noindex**: `X-Robots-Tag: noindex, nofollow` in `next.config.ts` più `metadata.robots`
+- **Anteprima admin**: con `state === 'draft'` mostrare comunque il documento se `getServerSession` restituisce una sessione admin, altrimenti il placeholder. Non tocca LOCKED #4, che riguarda `/client/*`
+- **Tracking**: alla prima render non-admin aggiornare `first_viewed_at` / `last_viewed_at` / `view_count`
+
+Nuovi componenti in `src/components/public/audit/`, uno per blocco, server components salvo slider e bottone stampa. **Non riusare** le 20 sezioni di `public/proposal/sections/`: sono saldate a `ProposalContent` con copy hard-coded.
+
+Da riusare: **`RichText.tsx`** per ogni testo libero (obbligatorio su output del modello — mai `dangerouslySetInnerHTML`), e le convenzioni visive esistenti (eyebrow `text-xs font-mono tracking-widest uppercase`, headline `text-5xl font-light`, card `border border-border rounded-xl p-8`).
+
+⚠️ Il deck preventivi è light-only (`bg-white` hard-coded in `ProposalDeck.tsx:139,141,156`, `PricingSection.tsx:46`) e viola la regola dei token in due punti (`TimelineSection.tsx:5-9`, `ClosingSection.tsx:20,34`). **Non replicare quei difetti**: solo token semantici, dual light/dark.
+
+**Leggibilità in B/N**: il livello di impatto non può dipendere dal colore. Etichetta + glifo — `●●● alto` / `●●○ medio` / `●○○ basso`.
+
+### PDF via print CSS
+
+Stessa pagina, stesso DOM, stesso record: il vincolo "una sola fonte" è soddisfatto per costruzione.
+
+In `src/app/globals.css` — oggi **zero regole print** in 218 righe — un blocco `@media print`:
+- Palette chiara forzata, `print-color-adjust: exact` dove serve
+- `break-inside: avoid` su ogni card problema e riga della tabella; `break-before: page` sui blocchi maggiori
+- Nascosti: bottone stampa, nav, controllo dello slider
+- **Slider prima/dopo**: a schermo interattivo, in stampa due immagini impilate con etichetta. Tecnica: entrambe le `<img>` **sempre** nel DOM, clippate in overlay via CSS a schermo; in `@media print` si toglie il clip e si impila. Nessun ramo JS, nessuna divergenza possibile
+- Bottone "Scarica PDF" sticky in alto a destra = client island con `window.print()`
+
+---
+
+## 9 · Admin
+
+Mutazioni come Server Actions colocate in `actions.ts` (niente REST per l'admin).
+
+- `src/app/admin/audit/page.tsx` — lista. Riusare `PageHeader`, `SearchInput`, badge di stato
+- `src/app/admin/audit/nuovo/` — **creazione manuale**: cliente o lead, livello, profilo, URL, importo → redirect all'editor
+- `src/app/admin/audit/[id]/edit/page.tsx` — RSC sottile + client component
+- `src/components/admin/audit/AuditEditor.tsx`
+- `src/app/admin/audit/actions.ts`
+- Voce in `AdminSidebar.tsx`
+
+**Pattern editor: `saveOfferEditor` + `OfferEditorClient`** (`src/app/admin/offers/actions.ts:177-274`, `src/components/admin/offers/OfferEditorClient.tsx`) — unico precedente di salvataggio a payload intero con array di figli:
+
+- Zod annidato con `z.array(findingSchema)` / `z.array(optimizationSchema)`, `id` opzionale sui figli
+- Nell'action: update degli scalari, loop sui figli con **upsert per presenza di `id`**, delete delle righe sparite, `sort_order: index` assegnato server-side
+- Client: array in `useState`, update immutabili via `.map`, `startTransition` + try/catch → `setSaveError`
+- ⚠️ **Il re-sync degli id dopo il primo salvataggio** (`OfferEditorClient.tsx:93-98`): senza, i figli appena creati vengono re-inseriti invece che aggiornati al salvataggio successivo. È il bug più facile da introdurre qui
+
+**Aggiungi / rimuovi / riordina righe**: non esiste nel codebase — `sort_order` oggi è write-once. `@dnd-kit/sortable` è già in `package.json` e usato in `KanbanBoard.tsx`: riusarlo, con l'indice dell'array che diventa `sort_order` al salvataggio.
+
+**Campi condizionali**: redesign e ottimizzazioni non si renderizzano se il livello non li prevede.
+
+**Bozza**: niente autosave (non esiste nel codebase, complessità sproporzionata). "Salva bozza" esplicito + avviso all'uscita con modifiche pendenti. Tutti i campi nullable. La **validazione di completezza scatta solo su "Consegna"**, sui soli blocchi pertinenti.
+
+**Consegna / Ritira**: transizioni guardate `WHERE id = ? AND state = ?` come `publishProposal` (`src/app/admin/preventivi/actions.ts:117-127`). Entrambe reversibili.
+
+**Automatismi** (budget 10 minuti): credito = `importo_pagato`, fasi già completate derivate dal livello, date da `published_at`/`measured_at`, ordinamento dei blocchi 4 e 7, analisi draftata dagli agent.
+
+---
+
+## 10 · Ingresso: manuale ora, Whop dopo
+
+Fase 1 = **solo creazione manuale**, che resta comunque un requisito permanente.
+
+Predisposto senza costruirlo: `origin` + `external_ref` sulla tabella, e `pipeline.ts` chiamabile da un webhook. L'intake del cliente è **ancora da definire** — la colonna `intake jsonb` accoglie qualunque forma prenderà, senza migration aggiuntive.
+
+---
+
+## 11 · Modifica al vincolo LOCKED #5 — richiede approvazione
+
+`CLAUDE.md` oggi: `5. No file hosting v1 — documenti come URL esterni`
+
+Nuova versione proposta:
+
+```
+5. No file hosting per i documenti — restano URL esterni.
+   Deroga (Phase 27, 2026-08-16): le immagini dell'audit (screenshot e
+   redesign) sono caricate su volume persistente e servite da
+   /api/uploads/[...path], con whitelist MIME e limite di dimensione.
+   Non estendere l'upload ad altre entità senza modificare questo vincolo.
+```
+
+---
+
+## 12 · GSD e memoria di progetto
+
+**Non c'è niente da costruire**: state file, roadmap e checkpoint automatico esistono già. `.planning/STATE.md` è il digest che comanda i comandi `/gsd-*`, `.planning/ROADMAP.md` traccia la posizione, `execute-plan.md` aggiorna STATE.md **dopo ogni piano**, e `.claude/rules/memory-discipline.md` è la regola scritta.
+
+Due difetti reali:
+
+1. **`.planning/config.json` non ha la chiave `hooks`.** Verificato: entrambi gli hook globali (`gsd-session-state.sh`, `gsd-phase-boundary.sh`) escono a vuoto senza `"hooks": { "community": true }`. Aggiungerla riattiva l'iniezione di STATE.md all'avvio sessione e il promemoria a ogni scrittura in `.planning/`. Una riga.
+2. **`gsd-sdk` e `gsd-tools` non sono nel PATH** (verificato: `not found`). Le mutazioni automatiche di STATE.md in `execute-plan.md` non hanno backend e ricadono su edit manuali — è il motivo per cui le fasi 13 e 26 hanno SUMMARY ricostruiti a posteriori.
+
+L'hook `Stop` in `.claude/settings.json` è solo advisory (`echo`) e guarda solo `src` e `.planning`: non nota modifiche a `STATUS.md` o `CLAUDE.md`.
+
+**Inquadramento**: nuovo milestone **v2.5 — Audit** via `/gsd-new-milestone`. Numerazione progressiva e mai riusata (l'ultima è 26 ⇒ si parte da **27**), come impone `.planning/PROJECT.md`.
+
+Da aggiornare a fine lavoro: `.planning/STATE.md`, `.planning/ROADMAP.md`, `STATUS.md`, `CLAUDE.md`.
+
+---
+
+## 13 · File toccati
+
+**Nuovi** — `scripts/spike-audit.ts` · `src/db/migrations/0017_audits.sql` · `src/lib/audit/{pipeline,agent,schema,fetch}.ts` · `src/lib/audit/template/{v1,index}.ts` · `src/lib/audit-queries.ts` · `src/lib/audit-view.ts` · `src/app/audit/[slug]/page.tsx` · `src/components/public/audit/*` · `src/app/admin/audit/**` · `src/components/admin/audit/AuditEditor.tsx` · `src/components/ui/ImageUploadField.tsx` · `src/app/api/uploads/[...path]/route.ts`
+
+**Modificati** — `src/db/schema.ts` · `src/proxy.ts` · `next.config.ts` · `src/app/globals.css` · `src/components/admin/AdminSidebar.tsx` · `CLAUDE.md` · `.planning/config.json` · `Dockerfile` + volume Coolify
+
+---
+
+## 14 · Verifica
+
+Non esiste test suite (nessun vitest/jest/playwright, nessuno script `test`). **`npm run build` è la verifica di riferimento** — fa il typecheck. `npm run lint` è `eslint` nudo.
+
+**Fase 1 (spike)** — gira su un sito reale, i problemi sono concreti e verificabili, la valutazione delle voci di checklist è ripetibile. È un giudizio tuo, non un test automatico.
+
+**Dopo:**
+1. `npm run build` — typecheck e compilazione
+2. Migration applicata in prod **prima** del push; verificare che le sei tabelle esistano
+3. Un audit di prova per ciascuno dei tre livelli, su entrambi i profili: i blocchi condizionali compaiono e spariscono correttamente
+4. Salvare a metà, ricaricare, nulla si perde. Salvare due volte di fila: i figli si aggiornano e **non si duplicano** (test del re-sync degli id)
+5. Riordinare i problemi, salvare, ricaricare: l'ordine regge
+6. Avviare un'analisi e **riavviare il container a metà**: la run va in `error` e "Rilancia" riparte senza perdere i passi completati
+7. Upload di un'immagine → redeploy → l'immagine è ancora lì (prova del volume)
+8. Slug consegnato in incognito: si apre. Bozza in incognito: placeholder. Bozza da admin loggato: si vede
+9. `X-Robots-Tag: noindex, nofollow` presente nella risposta
+10. **Stampa**: Cmd+P sul documento consegnato → interruzioni di pagina corrette, slider impilato in due immagini, nessun marcatore di lavorazione (bordi/testi colorati) sopravvissuto, e in **scala di grigi** sia i livelli di impatto sia i valori delle metriche restano distinguibili
+10b. **Rete disattivata dopo il primo caricamento**: i font restano quelli giusti (prova che sono self-hostati e che nessuna risorsa esterna è rimasta)
+11. Il tracking apertura si incrementa da visitatore e **non** dalla preview admin
+12. Consegnato un audit su `v1`, alzare `LATEST_TEMPLATE_VERSION` a `v2`: il consegnato continua a rendere `v1`, uno nuovo nasce `v2`
+13. Un audit su brand premium **non** propone mai voci con `registro='volume'`
+
+⚠️ Playwright non funziona contro `npm run dev` (la CSP blocca `eval`, i client component non si idratano). Per E2E usare il build di produzione.

.claude/plans/v2.5-audit-motore.md

@@ -0,0 +1,200 @@
+# Audit — motore multi-agente, rilevazioni e tracciamento
+
+## Context
+
+Il piano approvato il 2026-08-16 (`dovremmo-fare-una-cosa-woolly-puddle.md`) resta in vigore per struttura del documento, versionamento del template, rubrica checklist, editor admin, pagina pubblica e print CSS. **Questo file ne sostituisce tre parti** — §6 (motore), §7 (immagini) e il tracciamento in §5/§8 — e non tocca il resto.
+
+Cosa è successo da allora:
+
+- **Lo spike è girato su giojello.com** e ha prodotto un audit di buona qualità. Ma `psi: {}` — le rilevazioni PageSpeed sono fallite tutte per quota anonima esaurita. Quell'audit è stato scritto **con zero misurazioni**, solo HTML statico.
+- **Il 52% della checklist non è verificabile da HTML statico** (204 voci → 107 non verificabili; lo step `generale` 40 su 50). Barra di ricerca, widget carrello, hover, animazioni, banner cookie esistono solo a runtime.
+- **Il VPS non può ospitare Chromium**: 1.492 MB di RAM disponibili su 3.819, 736 MB già in swap, 2 vCPU, con Coolify/n8n/Gitea/Vaultwarden sopra. Il disco invece è libero (21 GB su 38). Immagine `node:20-alpine`, non supportata da Playwright.
+- **Il processo bersaglio è: incolli un URL, il motore fa ricerche incrociate con le API gratuite, esce un documento pronto da inoltrare.** Tu carichi a mano solo due immagini: hero prima e hero dopo, JPG ≤ 0,5 MB.
+
+### Decisioni
+
+| Punto | Decisione | Data |
+|---|---|---|
+| Renderer headless | **Nessuno, da nessuna parte.** Motore 100% in-app, self-service | 2026-08-18 |
+| Buco a runtime | Coperto da audit Lighthouse completi + screenshot renderizzato letto in visione + CrUX + Wayback | 2026-08-18 |
+| Immagini manuali | Solo le due del redesign, JPG ≤ 0,5 MB | 2026-08-18 |
+| Screenshot stato di fatto | Automatici, da PageSpeed | 2026-08-18 |
+| Tracciamento | Registro delle singole visite + evento stampa | 2026-08-18 |
+
+**Due decisioni del 2026-08-17 sono superate da questa revisione** e vanno corrette prima di eseguire (§8): il renderer locale sul Mac e la frase "la copia master è la cartella di cattura locale" scritta in `CLAUDE.md` — non esiste più nessuna cattura locale.
+
+---
+
+## 1 · Prerequisito bloccante — chiave PageSpeed e verifica dell'ipotesi
+
+Tutto il resto poggia su un'ipotesi **non ancora verificata**: la quota anonima risponde `429` e senza chiave non si prova. Primo passo, prima di scrivere codice:
+
+1. Creare un progetto Google Cloud, abilitare *PageSpeed Insights API* e *Chrome UX Report API*, generare una chiave (gratuita, nessuna carta). In `.env.local` e in Coolify come `PAGESPEED_API_KEY`.
+2. Una chiamata a mano, e **verificare che esistano davvero**:
+   - `lighthouseResult.fullPageScreenshot.screenshot.data` → `data:image/jpeg;base64,…` a pagina intera
+   - `lighthouseResult.audits` → l'insieme completo (~150 voci), non i 10 scalari che lo spike estrae oggi
+
+**Se lo screenshot a pagina intera non c'è**, ripiego su `lighthouseResult.audits["final-screenshot"]` (solo viewport, quindi di fatto l'hero — che è comunque il blocco più importante). **Se non c'è nemmeno quello**, l'analisi visiva esce dalla fase 1 e gli screenshot dello stato di fatto tornano manuali: cambia §5 di questo piano, non il resto.
+
+> ⚠️ Non costruire il sub-agent visivo prima di aver visto quel campo con i tuoi occhi.
+
+---
+
+## 2 · Le fonti — "tutte le api gratuite che servono"
+
+| Fonte | Cosa dà | Chiave | Alimenta |
+|---|---|---|---|
+| **PageSpeed Insights v5** (mobile + desktop) | ~150 audit Lighthouse, punteggi, screenshot renderizzato a pagina intera | sì, gratuita | blocco 3, finding tecnici, sub-agent visivo |
+| **CrUX API** | LCP/INP/CLS **p75 di utenti reali**, per origin e per URL | stessa chiave | blocco 3 — la distinzione lab/campo |
+| **Wayback CDX** | storico degli snapshot, diff del testo hero rispetto a 1/3/5 anni fa | no | la tesi "l'azienda è cresciuta, il sito no" |
+| **RDAP** (`rdap.org`) | età del dominio | no | contesto in blocco 3 |
+| **Mozilla HTTP Observatory** | voto sugli header di sicurezza | no | segnali di fiducia |
+| **Fetch diretto** | `robots.txt`, `sitemap.xml` (→ `pagine_indicizzate`), JSON-LD, `hreflang`, impronta della piattaforma | no | blocco 3, finding tecnici |
+| **Le pagine del sito** | già nello spike: home + fino a 3 pagine per profilo | no | verifica checklist |
+
+**Perché questo elenco e non altro:** ognuna di queste è una **rilevazione**, non una stima. È esattamente ciò che impone la disciplina sui numeri del piano approvato — un numero entra nel documento solo se misurato. CrUX in particolare porta dati di utenti veri, la cosa più difendibile che si possa scrivere in un audit.
+
+**Il guadagno più grande è già in casa e viene buttato via:** lo spike chiama PageSpeed e ne estrae 10 numeri. Gli audit Lighthouse coprono da soli una fetta consistente del 52% non verificabile — `color-contrast`, `tap-targets`, `font-size`, `image-alt`, `link-text`, `crawlable-anchors`, `structured-data`, `unsized-images`, `errors-in-console`, `viewport`, `canonical`. Sono verifiche fatte **sul DOM renderizzato**, cioè proprio quello che l'HTML statico non vede.
+
+---
+
+## 3 · Il motore
+
+`src/lib/audit/`, modellato su `src/lib/proposal/` ma multi-step e con fan-out:
+
+```
+src/lib/audit/
+  pipeline.ts    orchestratore: (auditId) => risultato. Non sa chi lo chiama
+  sources/       raccolta dati, nessun LLM
+    fetch.ts       pagine + estrazione testo (dallo spike, quasi invariato)
+    pagespeed.ts   PSI: audit completi + screenshot + estrazione scalari
+    crux.ts        dati di campo
+    history.ts     Wayback CDX + diff
+    signals.ts     RDAP, header, robots/sitemap/JSON-LD
+  agents/        un file per sub-agent, ognuno con prompt e schema Zod propri
+    checklist.ts   verificatore, Sonnet, batch da 12 per step di funnel
+    visual.ts      analisi visiva, Opus con input immagine
+    history.ts     scarto fra il sito di allora e l'azienda di oggi, Sonnet
+    technical.ts   audit Lighthouse + header + dati strutturati, Sonnet
+    synthesis.ts   sintetizzatore, Opus
+  schema.ts      Zod per ogni output di sub-agent + per la sintesi
+```
+
+**Sequenza.** Raccolta in parallelo (I/O di rete puro) → quattro sub-agent in parallelo, ognuno sul proprio materiale → sintetizzatore che riceve i quattro output e **incrocia**.
+
+**Cosa vuol dire "incrociate", in concreto.** I sub-agent producono osservazioni, non finding. È il sintetizzatore che le fonde:
+
+> checklist: "nessun segnale di fiducia sulla scheda prodotto" + tecnico: "nessun dato strutturato `Product`/`Review`" + storico: "il testo dell'hero non cambia dal 2021" + visivo: "le recensioni sono sotto tre schermate di scroll"
+> → **un solo finding**, con quattro evidenze indipendenti, invece di quattro finding deboli.
+
+Questo serve la regola di selezione del piano approvato: il documento promette "non un elenco di quaranta punti", e la forza sta nella selezione. Massimo 10 problemi, ordinati per impatto.
+
+**Tre cose che lo spike non fa e vanno fatte:**
+
+1. **Validazione Zod di ogni output di modello.** Lo spike fa `as Record<string, unknown>` e stampa. `proposal/schema.ts` è il precedente: `safeParse`, fallimento duro, nessun loop di riparazione.
+2. **Concorrenza limitata e retry.** Fan-out sì, ma con un tetto (4 chiamate contemporanee) e un retry con backoff sulle 429/529 di Anthropic. Lo spike non ha né l'uno né l'altro.
+3. **Heartbeat a ogni passo.** `audit_runs.heartbeat_at`; una run senza battito da N minuti va in `error`, "Rilancia" riparte dall'ultimo passo completato. È la mitigazione già prevista per il redeploy che uccide il job.
+
+**Da riusare invariati dallo spike:** i blocchi `SICUREZZA` e `NUMERI`, la funzione `fence()` che neutralizza i tag di chiusura, e l'estrazione del primo blocco `text` con guardia su `stop_reason === "max_tokens"` (più robusta di `content[0]` in `proposal/agent.ts`).
+
+**Impronta sul VPS:** I/O di rete e JSON. Nessun processo pesante, nessun Chromium. Il picco è la dimensione dello screenshot in memoria prima dell'invio ad Anthropic — vedi §7.
+
+---
+
+## 4 · Schema — differenze rispetto a §5 del piano approvato
+
+La migration resta `0017_audits.sql`, additiva e idempotente, applicata in prod **prima** del push. Rispetto all'elenco già approvato:
+
+**Nuova tabella `audit_visits`** — il registro delle singole visite:
+`id`, `audit_id` CASCADE, `occurred_at` default now, `event` CHECK `('view','print')`, `referrer`, `user_agent`, `ip_hash`. Indice su `(audit_id, occurred_at desc)`.
+
+L'IP **non si salva in chiaro**: SHA-256 di `ip + NEXTAUTH_SECRET` via Web Crypto, come già si fa per il digest del gate admin in `src/lib/admin-gate.ts`. Serve a distinguere due aperture dello stesso lettore da due lettori diversi, non a identificare qualcuno.
+
+**Campi aggiunti su `audits`** — separare laboratorio e campo, perché è la distinzione che rende credibile il blocco 3:
+`lcp_field`, `inp_field`, `cls_field` (numeric, da CrUX, nullable — un sito senza traffico sufficiente non ha dati di campo, ed è un'informazione anch'essa).
+
+**Restano come da piano approvato** le colonne di roll-up `first_viewed_at` / `last_viewed_at` / `view_count`: sono la lettura veloce per la lista admin, aggiornate insieme alla riga di `audit_visits`.
+
+**`screenshot_desktop_url` / `screenshot_mobile_url`** ora li scrive la pipeline, non tu.
+
+---
+
+## 5 · Immagini
+
+**Due upload manuali per audit**, non di più: `redesign_prima_url` e `redesign_dopo_url`. JPG, limite **512 KB**. Il componente `ImageUploadField` accetta `image/jpeg|png|webp` — non ha senso rifiutare un PNG per principio — ma il limite di dimensione è quello.
+
+**Due file scritti dalla pipeline**: gli screenshot PageSpeed mobile e desktop, decodificati da base64 e salvati come JPG sullo stesso volume.
+
+Quattro file per audit, circa 1,5 MB. Il volume Coolify su `/app/uploads` e la lettura via `src/app/api/uploads/[...path]/route.ts` con guardia sul path traversal restano come da §7 del piano approvato — con un margine molto più comodo di quanto si era dimensionato.
+
+> ⚠️ **Checkpoint bloccante.** Volume creato in Coolify **prima** del deploy, altrimenti gli upload si perdono a ogni redeploy.
+
+---
+
+## 6 · Tracciamento
+
+Un'isola client `<AuditVisitTracker>` montata nella pagina pubblica chiama una server action fire-and-forget:
+
+- **all'mount** → evento `view`
+- **su `window.print()`** e sull'evento `beforeprint` → evento `print`
+
+La server action, lato server, chiama `getServerSession`: **se c'è una sessione admin non scrive niente.** È così che l'anteprima admin non inquina i numeri — requisito già scritto nella verifica del piano approvato (test 11).
+
+Perché un'isola client e non una scrittura nel render RSC: la pagina ha `revalidate = 0` e quindi ri-esegue a ogni richiesta, ma scrivere sul DB dentro un render è un anti-pattern Next e conterebbe anche i prefetch e i bot. La convenzione del progetto è comunque "le mutazioni sono Server Actions".
+
+Lato admin: il registro visite compare nell'editor dell'audit, sotto forma di elenco cronologico.
+
+---
+
+## 7 · Rischi da mettere in conto
+
+- **Lo screenshot a pagina intera può essere altissimo** (una home lunga arriva a 10-15.000 px). Va ridimensionato prima di mandarlo a Opus, o mandato a fette. Non risolto: da misurare sul primo audit vero.
+- **Latenza PageSpeed**: 30-60 s per strategia, due strategie. Il job in background lo regge, ma incide sul tempo totale — stimare il totale della pipeline dopo il primo giro completo, non prima.
+- **Wayback e Observatory sono lenti e ballerini.** Ogni fonte deve fallire in modo non fatale, come già fa PageSpeed nello spike (`psi[s] = null` e si prosegue).
+- **CrUX non risponde per i siti a basso traffico.** Non è un errore: è un dato. Il documento deve saperlo dire ("non ci sono abbastanza visitatori perché Google raccolga dati di campo") invece di lasciare un buco.
+- **La ripetibilità è già stata vista traballare**: lo step `generale` ha dato 0 non conformi nel giro completo e 2 in quello isolato, a parità di sito e voci. Con il fan-out il rischio non diminuisce. Da tenere sotto osservazione al primo audit di prova.
+
+---
+
+## 8 · Da correggere prima di eseguire
+
+Due cose scritte ieri sono ora sbagliate:
+
+1. **`CLAUDE.md`, deroga a LOCKED #5** — dice "la copia master è la cartella di cattura locale". Non esiste più nessuna cattura locale. Sostituire con la formulazione di §11 del piano approvato, che è già corretta e non parla di copie locali.
+2. **`.planning/STATE.md`** — la decisione "il renderer headless gira in LOCALE sul Mac" va riscritta come "nessun renderer headless: il buco a runtime è coperto dagli audit Lighthouse e dallo screenshot PageSpeed". Il *perché* il VPS non regge Chromium resta valido e va tenuto: è la ragione per cui l'opzione non tornerà.
+
+Stessa correzione nel file di memoria persistente `project_clienthub_vps_no_headless.md`.
+
+---
+
+## 9 · File toccati
+
+**Nuovi** — `src/db/migrations/0017_audits.sql` · `src/lib/audit/pipeline.ts` · `src/lib/audit/sources/{fetch,pagespeed,crux,history,signals}.ts` · `src/lib/audit/agents/{checklist,visual,history,technical,synthesis}.ts` · `src/lib/audit/schema.ts` · `src/lib/audit/template/{v1,index}.ts` · `src/lib/audit-queries.ts` · `src/app/audit/[slug]/page.tsx` · `src/components/public/audit/*` (uno per blocco, più `AuditVisitTracker`) · `src/app/admin/audit/**` · `src/components/admin/audit/AuditEditor.tsx` · `src/components/ui/ImageUploadField.tsx` · `src/app/api/uploads/[...path]/route.ts`
+
+**Modificati** — `src/db/schema.ts` · `src/proxy.ts` (aggiungere `/audit` al matcher, con `rateLimit`) · `next.config.ts` (`X-Robots-Tag: noindex, nofollow`) · `src/app/globals.css` (blocco `@media print`) · `src/components/admin/AdminSidebar.tsx` · `CLAUDE.md` · `.planning/STATE.md` · Dockerfile + volume Coolify
+
+**Riusati senza modifiche** — `src/lib/rate-limit.ts` · `src/components/public/proposal/RichText.tsx` · `src/lib/admin-gate.ts` (per l'hash) · `src/app/admin/offers/actions.ts` come modello di editor a payload intero · `@dnd-kit/sortable` per il riordino
+
+---
+
+## 10 · Verifica
+
+Non c'è test suite: **`npm run build` è la verifica di riferimento** (fa il typecheck).
+
+**Prima di tutto** — la chiave PageSpeed funziona e `fullPageScreenshot` esiste davvero (§1). Se non esiste, fermarsi e rivedere §5.
+
+Poi, nell'ordine:
+
+1. `npm run build` pulito
+2. Migration applicata in prod **prima** del push; le sette tabelle esistono
+3. Un audit completo su giojello.com: **confrontare la quota di non verificabili con il 52% dello spike**. È la misura che dice se l'approccio senza Chromium ha funzionato
+4. Ogni numero nel documento consegnato ha una fonte rintracciabile in `audit_runs.raw`. Nessuna percentuale inventata
+5. Un sito senza dati CrUX: il documento lo dice, non lascia un buco
+6. Riavviare il container a metà analisi: la run va in `error`, "Rilancia" riparte senza rifare i passi completati
+7. Upload di un'immagine → redeploy → l'immagine è ancora lì (prova del volume)
+8. Aprire il documento consegnato in incognito: compare una riga in `audit_visits`. Aprirlo da admin loggato: **non** compare. Premere "Scarica PDF": compare una riga `print`
+9. Cmd+P sul documento: interruzioni di pagina corrette, slider impilato in due immagini, nessun marcatore di lavorazione sopravvissuto, e in **scala di grigi** impatti e metriche restano distinguibili
+10. Rete disattivata dopo il primo caricamento: i font restano quelli giusti (prova che sono self-hostati)
+11. I test 3, 4, 5, 8, 12 e 13 del piano approvato — blocchi condizionali per livello, salvataggio a metà, re-sync degli id dei figli, riordino, congelamento del template, e nessuna voce `registro='volume'` su un brand premium
+
+⚠️ Playwright non funziona contro `npm run dev` (la CSP blocca `eval`). Vale solo se un giorno servirà un E2E sul portale: usare il build di produzione.

.claude/plans/v2.5-modifiche-hub.md

@@ -0,0 +1,319 @@
+# Modifiche all'hub — dashboard, progetti, pipeline
+
+## Contesto
+
+Il 2026-08-18 hai elencato una serie di modifiche all'hub divise per sezione
+(dashboard, progetti, pipeline). La sessione si è fermata sul limite settimanale
+subito dopo aver lanciato l'esplorazione, e quel lavoro non è mai stato ripreso.
+Questo piano lo raccoglie.
+
+Il punto di partenza è che **quasi tutto quello che chiedi è calcolabile con i
+dati che l'hub già ha**: le categorie di offerta esistono, le fasi e i task hanno
+uno stato, i pagamenti hanno una data di incasso, le conversazioni sono già
+aggregate. Serve poco schema nuovo — una sola migration additiva — e molta
+query + UI.
+
+L'eccezione è l'ingresso da Whop per gli audit: dipende dal motore di analisi
+della v2.5, che è fermo alle sole fonti. Hai scelto di fare **prima le modifiche
+hub e poi il motore**, quindi quel blocco resta documentato ma non costruito.
+
+### Decisioni prese
+
+| Domanda | Scelta |
+|---|---|
+| Sequenza | Hub prima, motore audit dopo |
+| Fonte "Audit" negli analytics | È la tua **Entry Offer** — si legge da `offer_macros.category`, come Signature e Retainer |
+| Data di consegna attesa | **Derivata** da offerta + durata, con **override manuale** opzionale |
+| Ingresso lead | TidyCal + form sito — vedi il blocco C, dove c'è un vincolo che cambia le carte |
+
+---
+
+## Blocco A — Progetti
+
+Il blocco a rischio più basso e a resa più immediata. Da fare per primo.
+
+### A1 · Togliere il tab Commenti e il timer dalla lista
+
+Due rimozioni chieste esplicitamente.
+
+- **Tab "Commenti"** in [page.tsx:75](src/app/admin/projects/[id]/page.tsx#L75) e
+  [page.tsx:118-120](src/app/admin/projects/[id]/page.tsx#L118-L120), più l'import a riga 8.
+  **Non si perde niente**: ho verificato che `buildEntityMap()` in
+  [conversations-queries.ts:57](src/lib/conversations-queries.ts#L57) cammina
+  clienti → progetti → fasi → task → deliverable e raccoglie *tutti* i commenti
+  con la loro etichetta d'entità. `/admin/conversazioni` è un sovrainsieme
+  stretto di quel tab. Il campo `comments` in `ProjectFullDetail` diventa morto:
+  va tolto anche da [admin-queries.ts:567](src/lib/admin-queries.ts#L567) e dalla query.
+- **Colonna "Timer"** dalla lista progetti: `<TimerCell>` in
+  [ProjectRow.tsx:85](src/components/admin/ProjectRow.tsx#L85) e l'intestazione in
+  [projects/page.tsx:47](src/app/admin/projects/page.tsx#L47). Il timer resta dove
+  ha senso, dentro il progetto.
+
+### A2 · Mini-dashboard nel singolo progetto
+
+Una striscia sopra i tab, prima di `<Tabs>` in
+[projects/[id]/page.tsx:69](src/app/admin/projects/[id]/page.tsx#L69). **Nessuna
+query nuova**: `getProjectFullDetail` restituisce già tutto.
+
+**Finance** — incassato / contrattualizzato / residuo, da `payments` +
+`offersAcceptedTotal`; ore tracciate e €/h reale da `totalTrackedSeconds` e
+`targetHourlyRate` (già passato alla pagina a riga 24).
+
+**Avanzamento** — task `done` su totale, con barra. Stessa aritmetica del
+`progress_pct` già usato per le fasi.
+
+Riusa il pattern `MetricCard` di [admin/page.tsx:18](src/app/admin/page.tsx#L18):
+va estratto in `src/components/admin/MetricCard.tsx` e importato da entrambe.
+Scrivere la striscia **a token semantici** (`bg-card`, `text-muted-foreground`) —
+questa route è il cluster peggiore di DEBT-01 (~182 occorrenze di palette raw) e
+non va peggiorata.
+
+### A3 · Timer per task e fase
+
+Oggi `time_entries` ha solo `project_id`
+([schema.ts:245](src/db/schema.ts#L245)). Servono due colonne nullable.
+
+- **Migration `0018`** (dettagli in fondo): `phase_id`, `task_id` su
+  `time_entries`, entrambe `ON DELETE SET NULL`. Cancellare un task **non deve**
+  cancellare il tempo tracciato: è storico fatturabile, l'entry ricade a livello
+  progetto. `project_id` resta obbligatoria, quindi ogni entry è sempre
+  attribuita.
+- **Server actions** in [timer-actions.ts](src/app/admin/timer-actions.ts):
+  `startTimer` prende `phaseId`/`taskId` opzionali; stessa cosa per
+  `addManualTimeEntry`. La regola "un solo timer attivo alla volta" (righe 19-38)
+  resta com'è — vale globalmente, non per task.
+- **UI**: `<TimerCell>` su ogni riga task dentro
+  [PhasesTab.tsx](src/components/admin/tabs/PhasesTab.tsx), con il totale della
+  fase come somma dei suoi task. `TimerTab` continua a mostrare il totale progetto.
+
+---
+
+## Blocco B — Dashboard
+
+### B1 · Analytics per linea di prodotto
+
+Tre righe — **Entry (Audit), Signature, Retainer** — lette da
+`offer_macros.category`, che è già una taxonomy editabile da
+`/admin/impostazioni` ([taxonomy.ts:37](src/lib/taxonomy.ts#L37)). In produzione
+oggi ci sono esattamente quelle tre categorie.
+
+Per categoria:
+
+- **Iniziati questo mese** — `count(project_offers)` con `start_date` nel mese corrente.
+- **Totale anno** — `count` + somma `accepted_total` con `start_date` nell'anno.
+- **Incassato** — `payments` in stato `saldato` con `paid_at` nell'anno.
+
+L'incasso ha un problema di attribuzione da risolvere esplicitamente: i pagamenti
+stanno sul **progetto**, non sull'offerta. La regola:
+
+1. progetto con **una** offerta → tutto l'incasso va a quella categoria;
+2. progetto con **più** offerte → ripartito in proporzione ai rispettivi `accepted_total`;
+3. progetto **senza** offerta → riga separata **"Senza offerta"**, mostrata a video.
+
+Il terzo caso non va nascosto. Oggi in prod ci sono 5 progetti e 2 righe in
+`project_offers`: la maggior parte dell'incassato finirebbe lì, e vederlo è il
+modo per accorgersene.
+
+Nuovo modulo `src/lib/product-analytics.ts` (non gonfiare `analytics-queries.ts`),
+nuovo componente `src/components/admin/dashboard/ProductBreakdown.tsx`.
+
+> **Nota da verificare al primo giro:** l'unica Entry Offer in produzione si
+> chiama *"Sblocca Business"*. Se l'audit è un prodotto diverso, va creata la sua
+> `offer_macro` con categoria `Entry Offer` — è configurazione, non codice.
+
+### B2 · Timeline delle consegne
+
+Riguarda i progetti che **si consegnano** — Entry e Signature. I retainer sono
+continuativi e non hanno una consegna: restano fuori, filtrando su
+`offer_macros.offer_type = 'una_tantum'`.
+
+Per ogni progetto non archiviato:
+
+- **Consegna attesa** = `projects.due_date` se valorizzata, altrimenti
+  `project_offers.start_date + offer_micros.duration_months`. La colonna
+  `due_date` arriva con la migration 0018 ed è l'override manuale che hai chiesto.
+- **% completamento** = task `done` / task totali.
+- **% tempo trascorso** = `(oggi − inizio) / (consegna − inizio)`.
+- **Semaforo** — soglia ±10 punti: `in linea` dentro la banda, `in ritardo` se il
+  completamento è sotto, `in anticipo` se è sopra. Un progetto oltre la data di
+  consegna e non completo è `in ritardo` a prescindere.
+
+I progetti senza scadenza calcolabile vanno elencati sotto come **"senza
+scadenza"** invece di sparire — altrimenti un progetto senza offerta assegnata
+diventa invisibile proprio nella vista che dovrebbe segnalarlo.
+
+Query in `src/lib/delivery-queries.ts`, componente
+`src/components/admin/dashboard/DeliveryTimeline.tsx`. `StatusBadge` per il
+semaforo, Geist Mono per date e percentuali.
+
+### B3 · Inbox
+
+**Questo esiste già.** [MessagesWidget.tsx](src/components/admin/dashboard/MessagesWidget.tsx)
+mostra i clienti con messaggi non letti, l'anteprima dell'ultimo messaggio e il
+link "Rispondi →" verso `/admin/conversazioni`. È il widget stretto in colonna
+1/3, in fondo: probabilmente non l'hai visto perché sta sotto la piega.
+
+Quindi non si costruisce, si promuove:
+
+- fascia **a piena larghezza in cima** alla dashboard, sopra i KPI, e solo quando
+  c'è almeno un non letto;
+- 6 righe invece di 4, con **data relativa** e **etichetta dell'entità**
+  (`lastMessageAt` e `lastEntityLabel` sono già in `ConversationSummary`,
+  [conversations-queries.ts:8](src/lib/conversations-queries.ts#L8) — oggi non
+  vengono usati);
+- anteprima più lunga del messaggio.
+
+Nuovo layout in [admin/page.tsx](src/app/admin/page.tsx): Inbox → KPI →
+Timeline consegne → Prodotti → il resto.
+
+---
+
+## Blocco C — Pipeline: ingresso lead
+
+### Il vincolo che cambia le carte
+
+**TidyCal non ha webhook.** È scritto nella loro FAQ: nessun supporto nativo, e
+la strada suggerita è passare da Zapier / Make / Pabbly. Quello che TidyCal *ha*
+è una REST API con OAuth 2.0 e **Personal Access Token disponibile su tutti i
+piani** (si crea da `tidycal.com/integrations/oauth`), con endpoint sulle
+prenotazioni.
+
+Elementor Pro, invece, ha un'azione **Webhook** nativa in "Actions After Submit":
+si incolla un URL e lui fa POST dei campi del form. Se invece andate su Astro,
+il POST lo scrivete voi. In entrambi i casi è una chiamata in ingresso.
+
+Da qui la forma della soluzione: **un endpoint solo, sia per il form che per
+TidyCal**, e per TidyCal un pezzo in più che va a prendersi le prenotazioni.
+
+### C1 · Endpoint di ingresso — `POST /api/webhooks/lead`
+
+Un solo endpoint, indipendente da chi chiama.
+
+- **Guardia**: header `x-webhook-secret` confrontato con una env nuova
+  (`LEAD_WEBHOOK_SECRET`), stesso pattern di
+  [validate-slug/route.ts:7](src/app/api/internal/validate-slug/route.ts#L7) —
+  ma **senza** la scorciatoia "se non è configurato passa": questa route è
+  esposta a internet, secret assente deve voler dire 403.
+- **Rate limit** con `rateLimit()` da [rate-limit.ts](src/lib/rate-limit.ts),
+  bucket per IP. `src/proxy.ts` **non intercetta** `/api/*` (matcher a riga 120),
+  quindi la difesa è tutta dentro la route.
+- **Payload** validato con Zod: `name` obbligatorio, `email`/`phone`/`company`/
+  `notes` opzionali, più un `source` libero. Mappatura campi in un modulo a
+  parte così aggiungere una sorgente non tocca la route.
+- **Effetto**: crea un `lead` in stato `contacted` riusando le funzioni di
+  [lead-service.ts](src/lib/lead-service.ts). Se l'email esiste già, aggiorna
+  `last_contact_date` invece di duplicare.
+
+Questo è tutto ciò che serve per Elementor, ed è pronto in anticipo per Astro:
+la decisione Elementor-vs-Astro **non blocca niente**, perché il contratto è
+un POST JSON in entrambi i casi.
+
+### C2 · TidyCal — sincronizzazione a polling
+
+Senza webhook, l'unico modo pulito senza terze parti è andare a leggere.
+
+- `src/lib/tidycal.ts` — client con Personal Access Token in
+  `TIDYCAL_ACCESS_TOKEN`, che chiede le prenotazioni create dall'ultimo giro.
+- `GET /api/internal/tidycal-sync` — protetta da `INTERNAL_SECRET`, come le due
+  internal esistenti. Per ogni prenotazione nuova crea un lead con nome, email e
+  la data della call in `next_action_date`, e registra un'`activity` di tipo
+  `meeting`. Idempotente sull'id TidyCal, così rilanciarla non duplica.
+- **Schedulazione**: Coolify ha gli Scheduled Tasks. Un `curl` ogni 15 minuti
+  verso quella route. Non serve infrastruttura cron nell'app — e infatti nel
+  repo non ce n'è.
+
+**Prima di scrivere il client va guardata la documentazione vera dell'API**, che
+è dietro login (`tidycal.com/integrations` → API Keys) e non è indicizzata: forma
+esatta dell'endpoint prenotazioni, filtro per data, paginazione. È il primo passo
+del blocco, non un dettaglio: vale la regola già scritta in memoria — *ogni
+estrazione da API di terzi va vista funzionare, non dedotta dai docs*.
+
+Se l'API risultasse inadatta, il ripiego è Zapier/Make che POSTa su C1, che a
+quel punto esiste già.
+
+### C3 · "Alleggerire l'hub"
+
+Questa richiesta non ha ancora un perimetro. Non la pianifico al buio: quando i
+blocchi A e B sono in produzione ti porto l'elenco di cosa è davvero poco usato
+(`/admin/quotes` e `/admin/preventivi` convivono, `service_catalog` e
+`offer_services` sono legacy da DEBT-02) e decidi tu cosa togliere. Cancellare
+route è irreversibile e va fatto guardando, non indovinando.
+
+---
+
+## Blocco D — Whop → audit *(rinviato, dipende dal motore)*
+
+L'ingresso Whop è già predisposto nello schema: `audits.origin` accetta
+`'whop'` e `audits.external_ref` tiene il riferimento esterno
+([schema.ts:688-690](src/db/schema.ts#L688-L690)).
+
+Ma "partono gli agent e fanno il lavoro" oggi **non è possibile**: in
+`src/lib/audit/` ci sono solo le cinque fonti; agent, sintetizzatore e pipeline
+(AUD-06 → AUD-11) non sono scritti. Costruire il webhook adesso significa
+costruire un innesco che non innesca niente.
+
+Quando il motore c'è, il blocco è: `POST /api/webhooks/whop` con verifica firma →
+crea cliente + progetto con la Entry Offer assegnata (così l'audit compare
+automaticamente in B1 e B2) → crea l'`audit` con `origin='whop'` → accoda la run.
+
+---
+
+## Migration 0018 — additiva
+
+`src/db/migrations/0018_timer_scope_and_due_date.sql`, in parallelo alle stesse
+modifiche in [schema.ts](src/db/schema.ts) (drizzle-kit generate è rotto, i due
+file si tengono in pari a mano).
+
+```
+ALTER TABLE time_entries ADD COLUMN phase_id text REFERENCES phases(id) ON DELETE SET NULL;
+ALTER TABLE time_entries ADD COLUMN task_id  text REFERENCES tasks(id)  ON DELETE SET NULL;
+CREATE INDEX time_entries_phase_idx ON time_entries(phase_id);
+CREATE INDEX time_entries_task_idx  ON time_entries(task_id);
+ALTER TABLE projects ADD COLUMN due_date timestamptz;
+```
+
+Solo `ADD COLUMN` e `CREATE INDEX`: nessun DROP, nessun TRUNCATE, nessuna colonna
+rimossa — conforme a Data Safety (LOCKED). Le righe esistenti di `time_entries`
+restano valide con le due colonne a NULL, cioè "tempo di progetto".
+
+**Ordine di applicazione**, come da CLAUDE.md: prima a produzione via
+`ssh root@178.104.27.55` + `docker exec`, **poi** il push del codice che le usa.
+
+---
+
+## Ordine di esecuzione
+
+1. **A1** — le due rimozioni (nessuna dipendenza, effetto immediato)
+2. **Migration 0018** in produzione
+3. **A3** timer su task/fase · **A2** mini-dashboard progetto
+4. **B3** inbox (piccola) → **B1** analytics prodotto → **B2** timeline consegne
+5. **C1** endpoint lead → **C2** TidyCal, dopo aver letto l'API vera
+6. **C3** e **D** dopo, con le informazioni che oggi non abbiamo
+
+Commit per unità logica, come negli ultimi quattro.
+
+## Verifica
+
+Non c'è suite di test in questo progetto: **`npm run build` è la verifica di
+riferimento** (fa il typecheck), più `npm run lint`.
+
+Controlli manuali, in ordine:
+
+- **A1** — il progetto non mostra più il tab Commenti; gli stessi commenti si
+  vedono ancora in `/admin/conversazioni` con la loro etichetta d'entità; la
+  lista progetti non ha più la colonna Timer.
+- **A3** — timer avviato su un task: `time_entries` ha `task_id` valorizzato; il
+  totale della fase è la somma dei suoi task; il totale progetto non cambia.
+  Poi cancellare quel task e verificare che **l'entry sopravviva** con
+  `task_id` a NULL.
+- **A2 / B1 / B2** — confrontare ogni numero a video con la stessa query lanciata
+  a mano su prod via `psql`. Su un dataset di 5 progetti si controllano tutti a
+  occhio; è l'unico momento in cui questo è ancora possibile.
+- **B2** — mettere una `due_date` manuale su un progetto e verificare che vinca
+  sulla data derivata dall'offerta.
+- **C1** — `curl` con secret giusto (lead creato), con secret sbagliato (403),
+  senza secret (403), e ripetuto per verificare che non duplichi.
+- Dual light/dark su ogni schermata nuova, e nessuna classe palette raw.
+
+Il portale cliente non va toccato da nessuna di queste modifiche: `client-view.ts`
+non si tocca, quindi il vincolo LOCKED #2 non è in gioco.

.claude/rules/memory-discipline.md

@@ -16,7 +16,9 @@ Dopo **ogni** unità di lavoro conclusa — una fase, una migration applicata, u
 
 ## Cosa scrivere nella memoria persistente
 
-`~/.claude/projects/-Users-simonecavalli-Vault-IAMCAVALLI/memory/` — un file per fatto, più la riga di indice in `MEMORY.md`.
+`~/.claude/projects/-Users-simonecavalli-Vault-IAMCAVALLI-hub/memory/` — un file per fatto, più la riga di indice in `MEMORY.md`.
+
+⚠️ **La chiave finisce in `-hub`.** Quella senza suffisso (`…-Vault-IAMCAVALLI/memory/`) è la memoria del *workspace*, un altro posto con altri file: scriverci un fatto di ClientHub significa non ritrovarlo più, perché a inizio sessione qui viene iniettata solo quella con `-hub`. Da non confondere nemmeno con `.claude/memory/`, che è versionata nel repo — la distinzione sta in [`../CLAUDE.md`](../CLAUDE.md).
 
 Ci va quello che **non si deduce dal repo**: decisioni e il loro perché, vincoli operativi, cose che sono state provate e non funzionano. Non ci va quello che il codice già dice: struttura, cronologia dei fix, contenuto di `CLAUDE.md`.
 

.claude/settings.json

@@ -18,6 +18,28 @@
     ]
   },
   "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Write|Edit|MultiEdit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/guardia-migration.sh"
+          }
+        ]
+      }
+    ],
+    "PostToolUse": [
+      {
+        "matcher": "Write|Edit|MultiEdit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/guardia-token.sh"
+          }
+        ]
+      }
+    ],
     "Stop": [
       {
         "hooks": [
@@ -28,16 +50,5 @@
         ]
       }
     ]
-  },
-  "enabledPlugins": {
-    "impeccable@impeccable": true
-  },
-  "extraKnownMarketplaces": {
-    "impeccable": {
-      "source": {
-        "source": "github",
-        "repo": "pbakaus/impeccable"
-      }
-    }
   }
 }

.claude/skills/audit/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: audit
+description: Far girare le fonti di rilevazione dell'audit sito di ClientHub su un URL e capire cosa e' stato misurato e cosa no. Da usare quando si lavora al motore audit v2.5, quando serve una rilevazione su un sito reale, quando si vuole sapere se una fonte risponde, o prima di scrivere qualsiasi pezzo del documento di audit.
+---
+
+# Audit — le rilevazioni, e cosa vale come misura
+
+Il motore v2.5 **non e' scritto**. Quello che esiste, e che questa skill mette in moto,
+sono le fonti di rilevazione: nessun LLM, nessun database, nessun browser headless.
+
+## Due attrezzi, due domande diverse
+
+| Comando | Cosa fa | Quando |
+|---|---|---|
+| `npx tsx scripts/audit-fonti.ts <url>` | Le **cinque fonti** di `src/lib/audit/sources/` — pagine, CrUX, PageSpeed, storico Wayback, segnali. Puramente meccanico | «Cosa si riesce a misurare su questo sito?» |
+| `npx tsx scripts/spike-audit.ts <url>` | Verifica le **264 voci di checklist** con Sonnet 5, poi sintetizza con Opus 5. Volutamente **isolato** da `src/`: non importa nulla, non tocca il DB | «Cosa c'e' che non va, in parole?» |
+
+Opzioni comuni: `--profilo=servizi|ecommerce`, `--no-psi` (salta PageSpeed, che da solo
+vale meta' del tempo). Riferimento misurato il 2026-08-26 su `giojello.com`: cinque fonti
+su cinque, **42,7 s** in tutto, PageSpeed 34,2 s. Se una fonte tace, **quella e' la notizia** —
+va riportata, non aggirata.
+
+`PAGESPEED_API_KEY` viene letta dall'ambiente o da `.env.local`. Senza, PageSpeed e CrUX
+rispondono a vuoto **senza errore**: lo script lo dice in testa, leggerlo.
+
+Il grezzo finisce in `audit-fonti-<dominio>.json` (gitignorato). E' li' che ogni numero del
+documento dovra' essere rintracciabile.
+
+## Le tre regole che il motore erediterà
+
+Non sono preferenze. Sono gia' costate, e stanno per esteso in `STATUS.md` § Lezioni operative.
+
+1. **Un numero entra solo se e' stato misurato.** Rintracciabile nel grezzo, e nel motore in
+   `audit_runs.raw`. Nessun numero dedotto, arrotondato o ricordato.
+
+2. **Laboratorio e campo non si fondono — la differenza *e'* il risultato.** Su giojello.com
+   Lighthouse dava `server-response-time` **7 ms** e CrUX TTFB p75 **3.553 ms con l'1% nel
+   verde**: il server risponde in fretta al datacenter Google e lento a tutti gli altri. Due
+   numeri con lo stesso nome verrebbero fusi in uno solo — per questo il campo si chiama
+   `risposta_server_ms` e non `ttfb_ms`.
+
+3. **Un punteggio va sempre con la sua data.** Performance mobile 52, poi 64 sullo stesso sito
+   mezz'ora dopo. Mai presentato come una costante del sito.
+
+E una regola di metodo che vale per ogni fonte nuova: **ogni estrazione da un'API di terzi va
+vista funzionare, non dedotta dai docs.** Scrivendo `sources/`, due estrazioni prese dalla
+documentazione hanno restituito valori vuoti *senza errore* — `largest-contentful-paint-element`
+non esiste piu' e `configSettings.screenEmulation` non esiste affatto nelle risposte pubbliche.
+Trovate solo perche' le fonti sono state fatte girare su un sito vero.
+
+## Perche' niente browser headless
+
+Misurato il 2026-08-17 sul VPS: **1,5 GB di RAM liberi su 3,8**, Chromium ne prende 500 MB–1 GB
+→ OOM kill sui servizi con dati reali. Verificato il 2026-08-18 che non serve comunque: 153 voci
+si verificano sul DOM renderizzato che PageSpeed restituisce, e lo screenshot buono e'
+`final-screenshot`, non `fullPageScreenshot`.
+
+## Lo stato di v2.5, per non ripartire dal posto sbagliato
+
+**In pausa dal 2026-08-19** per scelta: prima le modifiche all'hub, poi il motore.
+
+| Pezzo | Dove | Stato |
+|---|---|---|
+| Schema, 7 tabelle + rubrica 264 voci | `0017_audits.sql`, `checklist_items` | in produzione |
+| Le cinque fonti | `src/lib/audit/sources/` | **in prod ma inerti**: nessuna route le chiama |
+| Agent, sintetizzatore, pipeline, editor, pagina | `src/lib/audit/`, `src/app/{admin/audit,audit}` | **da scrivere** |
+
+I piani stanno in [`../../plans/`](../../plans/): `v2.5-audit-documento.md` (i tre livelli
+Radiografia / Prima-Dopo / Rotta come configurazioni di **un unico** documento) e
+`v2.5-audit-motore.md` (raccolta in parallelo → quattro sub-agent → sintetizzatore che
+**incrocia** le osservazioni in massimo 10 finding).
+
+## L'agente, quando lo progetteremo
+
+Va in `.claude/agents/audit-*.md`, non qui. Non esiste ancora e non va abbozzato: il design
+dei quattro sub-agent cambiera' scrivendo il motore. Quando nascera' eredita le tre regole
+qui sopra — sono il perimetro, non il contorno.

.claude/skills/preventivo/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: preventivo
+description: Lavorare sulla pipeline che genera i preventivi di ClientHub (src/lib/proposal/) senza romperla. Da usare quando si modifica il prompt, lo schema Zod, il montaggio o la resa di un preventivo, quando una generazione fallisce con "Contenuto AI non valido", quando una sezione del documento esce vuota, o prima di pubblicare una proposta a un cliente.
+---
+
+# Preventivo — la catena e come non spezzarla
+
+Il preventivo lo genera **l'app**, da `/admin/preventivi/genera`. Questa skill non contiene
+un prompt di generazione e non ne va aggiunto uno: il prompt vive in `agent.ts` ed e' l'unico.
+Un secondo prompt qui resterebbe indietro rispetto a quello vero senza che nessuno se ne accorga.
+
+## La catena: quattro file che devono dire la stessa cosa
+
+```
+src/lib/proposal/agent.ts          il prompt chiede N campi          ─┐
+src/lib/proposal/schema.ts         lo Zod pretende quegli N campi     │  se non
+src/lib/proposal/assemble.ts       li impacchetta con prezzi+profilo  │  coincidono,
+src/components/public/proposal/    ProposalDeck + sections/ li resa  ─┘  si rompe
+```
+
+**Si tocca il prompt, si riapre lo schema. Sempre.** I due fallimenti hanno forma diversa e
+solo uno si vede subito:
+
+| Cosa hai fatto | Cosa succede |
+|---|---|
+| Campo aggiunto allo **schema**, non al prompt | `ProposalContentSchema.safeParse` fallisce → **ogni** generazione muore con «Contenuto AI non valido». Rumoroso, si scopre subito |
+| Campo aggiunto al **prompt**, non allo schema | Zod lo scarta in silenzio. Il documento esce senza quella parte, e te ne accorgi davanti al cliente |
+| Campo nello schema, nessuna `<Section>` che lo legge | Generazione verde, sezione assente. Il piu' subdolo: niente segnala l'errore |
+
+Quando aggiungi un campo, il giro completo e' **quattro file**: prompt in `buildUserPrompt`,
+schema Zod, eventuale passaggio in `assembleProposal`, e la sezione in
+`src/components/public/proposal/sections/` piu' la riga in `ProposalDeck.tsx` che la monta.
+I vincoli di cardinalita' stanno nello schema (`.min(3).max(5)` sui problemi, `.length(5)` sui
+nodi del diagramma, `.min(4).max(10)` sulla matrice): se li cambi li' e non nel prompt, il
+modello continua a produrre il numero vecchio e Zod lo rifiuta.
+
+## Prezzi: cosa puo' vedere il cliente
+
+Vincolo **LOCKED #2** (`../../CLAUDE.md`): al cliente vanno i totali, mai le righe di prezzo.
+
+`PricingSection.tsx` renderizza `tier.publicPrice ?? tier.servicesTotal` e il **nome** dei
+servizi — corretto. Ma `assembleProposal` mette in `content.offer.tiers[].services[].unitPrice`
+anche il prezzo unitario, e `ProposalDeck` e' `"use client"`: riceve l'intero `proposal` come
+prop da un server component, quindi **tutto** l'oggetto finisce serializzato nel payload RSC
+della pagina, renderizzato o no.
+
+E' la stessa trappola del gate OTP annotata in `STATUS.md` — *sparire a schermo non e' sparire*.
+Prima di toccare la pagina pubblica, e prima di mandare un preventivo a un cliente che potrebbe
+aprire il sorgente:
+
+```bash
+curl -s https://<host>/preventivo/<slug> > /tmp/p.html
+LC_ALL=C grep -c unitPrice /tmp/p.html      # atteso a regime: 0
+```
+
+Se e' > 0, la correzione non e' nascondere la sezione: e' una proiezione client-safe in
+`assemble.ts` o al confine del componente, come gia' fa `src/lib/client-view.ts` per il portale.
+
+## Prima di pubblicare
+
+1. **Preflight sui dati finti** — `./check-profilo.sh` da questa cartella. `profile.ts` e' uno
+   **snapshot**: quello che c'e' dentro al momento della generazione finisce in
+   `proposals.content` e ci resta anche se poi correggi il file.
+2. **Le citazioni sono verbatim o non sono.** Il prompt lo impone; verificarlo a campione contro
+   il transcript e' il controllo che nessuna macchina fa al posto tuo. Una citazione inventata
+   in un preventivo e' peggio di un preventivo senza citazioni.
+3. **Copy** — italiano, registro di `../../../../brand/voce.md`, e **nessun numero che non stia
+   in `../../../../brand/prove.md` marcato divulgabile** (`../../../../.claude/rules/lingua-e-tono.md`).
+   ⚠️ `brand/` sta **fuori dal repo hub**: su un clone senza il workspace questo passo si salta
+   dichiarandolo, non si finge di averlo fatto.
+4. **Stato** — `draft` non e' visibile (la pagina risponde «non ancora disponibile»).
+   Pubblicare = `publishProposal` in `src/app/admin/preventivi/actions.ts`.
+
+## Come si prova davvero
+
+- `npm run build` e' **la verifica di riferimento**: non esiste test suite, e il build fa il
+  typecheck. Verde qui significa «i tipi tornano», non «il documento e' giusto».
+- Per vedere l'output serve una **generazione vera** dall'admin, con un'offerta e almeno un
+  transcript. In locale oggi **non si puo'**: `.env.local` non autentica piu' contro il DB
+  (dal 2026-08-21, vedi `STATUS.md`). Si guarda in produzione.
+- Un preventivo si legge a schermo prima di mandarlo. «Buildato» non e' «funziona», e
+  «generato» non e' «verificato».
+
+## Note sulla chiamata al modello
+
+`agent.ts` usa `max_tokens: 8192` per uno schema che chiede fino a 5 problemi + 5 soluzioni +
+matrice. Se la risposta viene troncata, il fallimento **non** dice «troncata»: dice
+«L'AI ha prodotto JSON non valido», e manda a cercare nel posto sbagliato. Se capita,
+controllare `message.stop_reason === "max_tokens"` prima di dare la colpa al parsing.

.claude/skills/preventivo/check-profilo.sh

@@ -0,0 +1,49 @@
+#!/usr/bin/env bash
+# Preflight: src/lib/proposal/profile.ts contiene dati placeholder?
+#
+# profile.ts e' uno SNAPSHOT: finisce dentro proposals.content al momento della
+# generazione e ci resta. Un placeholder spedito una volta non si corregge piu'
+# modificando il file — va rigenerato il preventivo.
+#
+# exit 0 = pulito · exit 1 = placeholder trovati
+set -uo pipefail
+
+ROOT=$(cd "$(dirname "${BASH_SOURCE[0]}")/../../.." && pwd)
+F="$ROOT/src/lib/proposal/profile.ts"
+[ -f "$F" ] || { echo "profile.ts non trovato in $F" >&2; exit 1; }
+
+# Ogni riga: etichetta|regex. Sono i segni concreti di "da riempire".
+PATTERNS=(
+  'testimonianza segnaposto|→ Aggiungere'
+  'nome cliente finto|"Cliente [0-9]"'
+  'ruolo generico|role: "Professione"'
+  'campo da compilare|// → '
+  'dominio sbagliato (il brand e iamcavalli.net)|iamcavalli\.com'
+)
+
+TROVATI=0
+for p in "${PATTERNS[@]}"; do
+  ETICHETTA="${p%%|*}"; RE="${p#*|}"
+  N=$(grep -cE "$RE" "$F" || true)
+  if [ "$N" -gt 0 ]; then
+    printf '  ✗ %-48s %s occorrenz%s\n' "$ETICHETTA" "$N" "$([ "$N" = 1 ] && echo a || echo e)"
+    TROVATI=$((TROVATI + N))
+  fi
+done
+
+if [ "$TROVATI" -gt 0 ]; then
+  cat >&2 <<'MSG'
+
+BLOCCO — profile.ts spedisce dati placeholder in ogni preventivo generato.
+
+Non si riempiono a occhio: i numeri divulgabili stanno in brand/prove.md, che oggi
+e' ancora `stato: scheletro-intervista`. Finche' non sono verificati, la mossa giusta
+non e' inventare — e' non renderizzare il blocco.
+
+Regola: ../../../.claude/rules/lingua-e-tono.md — «un numero affermato con sicurezza e
+mai verificato e' il modo piu' veloce per bruciare la credibilita' che il tono costruisce».
+MSG
+  exit 1
+fi
+
+echo "  ✓ profile.ts pulito"

.env.example

@@ -16,6 +16,11 @@ INTERNAL_SECRET=generate-with-openssl-rand-base64-32
 RESEND_API_KEY=re_xxxxxxxxxxxxxxxxxxxxxxxx
 RESEND_FROM=Nome Mittente <no-reply@iamcavalli.net>
 
+# Base pubblica dei link nelle email (pulsante "Apri la conversazione" della
+# notifica di tag). Opzionale: se manca si usa NEXTAUTH_URL, che in ogni
+# ambiente e' gia' l'origine giusta. Serve solo se le due devono divergere.
+# APP_BASE_URL=https://hub.iamcavalli.net
+
 # Ingresso lead da fuori (form del sito, bridge Zapier/Make) su
 # POST /api/webhooks/lead, header x-webhook-secret.
 # A differenza di INTERNAL_SECRET questa route e' esposta a internet: se la

.gitignore

@@ -49,3 +49,6 @@ next-env.d.ts
 
 # Output degli spike audit (dati di siti di clienti, non vanno committati)
 spike-audit-*.json
+
+# Grezzo delle rilevazioni audit (npx tsx scripts/audit-fonti.ts)
+audit-fonti-*.json

.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. Modifiche hub: A, B, C1, rifiniture, chat a canali (0021) e modifica messaggi + firma (0022) in prod; C2 (TidyCal) bloccato sulle credenziali API. Stati dei task nel portale: in prod 2026-08-22, bundle verificato, mai visto a schermo. Niente della chat e' stato provato a mano: .env.local non autentica piu'."
-last_updated: "2026-08-22T12:10:00.000Z"
-last_activity: 2026-08-22 -- stati dei task leggibili nel portale cliente (icone, pill, legenda)
+stopped_at: "v2.5 in PAUSA. Modifiche hub: A, B, C1, rifiniture, chat a canali (0021), modifica messaggi + firma (0022), stati task e date pagamenti (0023) in prod; C2 (TidyCal) bloccato sulle credenziali API. Conversazioni (scrittura per primo, menzioni, mail sul tag) pushata il 2026-09-01, nessuna migration, MAI provata a mano. Nulla del portale e' stato visto a schermo: .env.local non autentica piu', serve ?preview=1 in prod. Il riquadro 'Prossimo pagamento' non compare finche' nessuna rata ha una due_date."
+last_updated: "2026-09-01T00:15:00.000Z"
+last_activity: 2026-09-01 -- conversazioni: scrivere per primo, menzioni, mail sul tag. Pushata dopo aver recuperato l'accesso a gitea dalla CLI admin
 progress:
   total_phases: 4
   completed_phases: 0
@@ -37,20 +37,18 @@ Phase 27 resta a metà — schema e fonti in prod, resto da scrivere.
 | C1 — `POST /api/webhooks/lead` | ✅ in produzione, provato contro il DB vero |
 | C2 — TidyCal | ⛔ **[BLOCCANTE]** vedi sotto |
 | C3 — Alleggerire l'hub | ⏸️ senza perimetro |
-| Rifiniture — tassonomie, "In revisione", tab pagamenti, riordino task | ✅ in prod 2026-08-20 (migration `0019`) |
+| Rifiniture — tassonomie, tab pagamenti, riordino task | ✅ in prod 2026-08-20 (`0019`) |
 | Portale cliente — stepper compatto/full-width, card offerta | ✅ in prod 2026-08-21 (`0020`); override provato su Caruso Speaker |
-| Chat a canali — portale + inbox admin per canale | ✅ in prod 2026-08-21 (`0021`); build verde, **mai provata a mano** |
-| Chat — modifica messaggi + firma admin da `settings` | ✅ in prod 2026-08-21 (`0022`); menzioni rimandate, manca l'attribuzione |
-| Portale — stati task leggibili (forma + pill + legenda) | ✅ in prod 2026-08-22 (`2e9bd2a`, `8b54f48`); bundle verificato, **mai visto a schermo** |
+| Chat — canali, modifica messaggi, firma admin | ✅ in prod 2026-08-21 (`0021`, `0022`); **mai provata a mano**; manca l'attribuzione |
+| Conversazioni — scrivere per primo, menzioni `@Nome`, mail sul tag | ✅ pushata 2026-09-01 (`41530b5`), nessuna migration. Menu dei tag corretto lo stesso giorno: mostrava **una riga per alias** invece che per persona. Build + lint puliti, 23 test sul parser e sul menu; **nessuna mail di tag mai partita davvero** |
+| Portale — stati task (forma, pill, legenda, «Cancellata») + date dei pagamenti | ✅ in prod 2026-08-22 (`2e9bd2a`, `8b54f48`, `fe76789`, migration `0023`); **mai visto a schermo**, nessuna `due_date` ancora inserita |
 | D — Whop → audit | ⏸️ dipende dal motore v2.5 |
 
 Progress: [███░░░░░░░] 25% (v2.5)
 
 ## Dove sta cosa
 
-**Fuori dal repo, e senza questi niente è ricostruibile:** i piani in `~/.claude/plans/`
-— `…woolly-puddle.md` (documento audit), `…radiant-valley.md` (motore),
-`sei-arrivato-qua-search-recursive-kettle.md` (modifiche hub).
+I piani della milestone sono **nel repo dal 2026-08-26**: `.claude/plans/v2.5-*.md`.
 
 | Cosa (audit) | Dove | Stato |
 |---|---|---|
@@ -64,7 +62,7 @@ Progress: [███░░░░░░░] 25% (v2.5)
 Raccolta in parallelo (nessun LLM, nessun browser headless) → quattro sub-agent →
 sintetizzatore che **incrocia** le osservazioni in massimo 10 finding. Vincolo che
 regge tutto: **un numero entra solo se misurato**, rintracciabile in `audit_runs.raw`.
-Passo per passo in `STATUS.md` e in `…radiant-valley.md`.
+Passo per passo in `STATUS.md` e in `.claude/plans/v2.5-audit-motore.md`.
 
 ## Accumulated Context
 
@@ -72,6 +70,10 @@ Passo per passo in `STATUS.md` e in `…radiant-valley.md`.
 
 Log completo in `PROJECT.md`. Vive per il lavoro corrente:
 
+- **[2026-09-01] Una lista che serve a leggere non è una lista da offrire in scrittura** — il menu dei tag mostrava tre voci (nome, brand, nome di battesimo) per una persona sola, perché gli era stata passata la stessa lista che il parser usa per **riconoscere** un tag nel testo. Sono due domande diverse: *come lo si può scrivere* (tutti gli alias, invisibili) e *chi si può scegliere* (una riga per destinatario). Ora `MentionTarget` le tiene separate — `label` per il menu, `aliases` per la rilettura — e il filtro passa da `normalizeForSearch`, la stessa normalizzazione del parser: con un `toLowerCase()` a parte, digitare «nicolo» non troverebbe «Nicolò» nel menu mentre nel messaggio verrebbe riconosciuto. Il difetto scalava peggio del valore: con tre contatti sarebbero state nove righe.
+- **[2026-09-01] L'accesso a Gitea si recupera dalla sua CLI, non dal web** — il push rispondeva 403 (la credenziale nel portachiavi leggeva ma non scriveva) e l'account web non era piu' accessibile, quindi la via del browser era chiusa in partenza. Si rientra da dentro il container: `docker exec -u git gitea-tgw04ws48sogkso84oogwckk gitea admin user change-password` per la password e `... generate-access-token --scopes write:repository --raw` per il token del push. Il token va messo nel portachiavi con `git credential approve`, **non** nell'URL del remote: li' finirebbe in chiaro dentro `.git/config`. Da ricordare perche' senza push non esiste deploy — Coolify parte da `main` e basta.
+- **[2026-08-22] Un task cancellato esce dai denominatori, non dalla lista** — resta visibile barrato (il cliente ha letto quella voce e deve capire che fine ha fatto) ma non conta, via un solo `countsTowardProgress()` in `task-status.ts`: contarlo terrebbe la fase sotto il 100% per sempre, contarlo come fatto racconterebbe una consegna mai avvenuta. Se in una fase restano solo cancellati torna «Da iniziare»: degenere, ma «Completata» mentirebbe.
+- **[2026-08-22] Le date dei pagamenti sì, gli importi per riga no** — LOCKED #2 parla di cifre, non di date. Salvate a **mezzogiorno UTC** (a mezzanotte il giorno civile a Roma è già quello dopo) e contate sui giorni civili a Roma in `src/lib/payment-dates.ts`, lo stesso modulo del futuro promemoria email: mail e portale non devono contraddirsi su quanti giorni mancano.
 - **[2026-08-20] Gli importi scritti a mano non si ricalcolano** — `amount_locked` esclude la riga da `rescalePayments`, e lo scarto fra somma rate e totale si dichiara invece di aggiustarlo. Il backfill dell'ordine rate va per `percent DESC`, non per `ctid`: 3 progetti su 5 erano già scombinati e l'ordine fisico avrebbe fissato l'errore.
 - **[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.
@@ -93,7 +95,9 @@ Log completo in `PROJECT.md`. Vive per il lavoro corrente:
 
 ## Session Continuity
 
-Last session: 2026-08-22
-Stopped at: **stati dei task leggibili nel portale cliente.** Nella Timeline lo stato era solo un cerchietto colorato — ambra e violetto indistinguibili a 20px, e tre stati su quattro senza alcun testo. Ora le quattro icone si distinguono per **forma** (vuoto → punto → spunta vuota → spunta piena), la pill di testo sta solo sui due stati ambigui, l'header della fase conta i task in attesa anche a card chiusa, e una legenda dice chi revisiona e che **ogni pagina include un giro di revisione**. La correzione che conta: **«In revisione» significa «aspetta l'OK del cliente», non controllo qualità interno** come scrive `5547e55` — è uno stato che *richiede un'azione*, e per questo non poteva restare muto. Barra di avanzamento invariata di proposito: cambia il tipo di lavoro, non l'avanzamento. Build, typecheck e lint verdi, nessuna migration. In produzione (`2e9bd2a`, `8b54f48`) col bundle verificato dentro il container, ma **mai visto a schermo**: il portale sta dietro il gate OTP e l'anteprima vuole una sessione admin.
-Next: (1) verificare in prod con `?preview=1` su **Caruso Speaker, fase «3 - Esecuzione»** — l'unica dove «In corso» e «In revisione» convivono (4 + 2 su 11), quindi l'unica dove si vede se ora si distinguono; (2) provare la chat in prod: modificare un messaggio admin e vederlo cambiare da solo entro ~20s senza duplicarsi; (3) sbloccare TidyCal con token o documentazione; (4) `LEAD_WEBHOOK_SECRET` su Coolify, senza cui `/api/webhooks/lead` risponde 403 a tutti; (5) poi v2.5 da `src/lib/audit/schema.ts` + `agents/`.
+Last session: 2026-08-26
+Stopped at: **stato task «Cancellata» + date dei pagamenti nel portale** (`fe76789`, migration `0023` applicata a prod prima del push). Un task tolto dal lavoro ora ha dove stare: **X nel cerchio, titolo barrato**, pill «Cancellata» — l'unico stato chiuso con la pill, perché «Fatto» e «Cancellata» sono entrambi barrati e scambiarli significa credere consegnato ciò che non esiste. Esce da **tutti** i denominatori via `countsTowardProgress()`. Nel Kanban cliente la colonna compare solo se piena (mai nascosta se ha dentro qualcosa); nell'admin c'è sempre, ed è così che si cancella un task. Lato pagamenti: `payments.due_date` (nullable, più indice parziale per il futuro promemoria email), riquadro «Prossimo pagamento» con conto alla rovescia in parole e rosso se scaduto, «Scade il…» / «Pagato il…» su ogni riga, **zero importi**. Admin: campo Scadenza per rata, «Incassato nel mese» → «Incassato il» (giorno; le analytics raggruppano per mese e non se ne accorgono). Build, typecheck e lint verdi.
+**2026-08-26 — architettura `.claude/`**: skill `/preventivo` e `/audit`, due hook di guardia, piani nel repo. Nessun tocco al prodotto. Le due cose trovate e non risolte sul preventivo → `STATUS.md`.
+
+Next: (0) **[SICUREZZA] rigenerare il token Gitea creato il 2026-09-01**: e' stato incollato in chat, quindi va considerato esposto. Si revoca da Settings -> Applications e si rifa'; (1) verificare in prod con `?preview=1` **entrambe** le cose: stati task su **Caruso Speaker, fase «3 - Esecuzione»** (l'unica con «In corso» e «In revisione» insieme, 4 + 2 su 11) e box pagamenti — ma prima **inserire una scadenza** dal tab Pagamenti, altrimenti il riquadro non compare per definizione; (2) due `paid_at` storici valgono il primo del mese (2026-03-01, 2026-01-01, scritti dal vecchio selettore a mese) e il cliente ora li legge come «Pagato il 1 mar 2026»: correggerli se il giorno vero era un altro; (3) provare la chat in prod: modificare un messaggio admin e vederlo cambiare da solo entro ~20s senza duplicarsi; (4) sbloccare TidyCal con token o documentazione; (5) `LEAD_WEBHOOK_SECRET` su Coolify, senza cui `/api/webhooks/lead` risponde 403 a tutti; (6) poi v2.5 da `src/lib/audit/schema.ts` + `agents/`.
 Resume file: None

CLAUDE.md

@@ -4,6 +4,10 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
 
 # ClientHub
 
+> Progetto del workspace [IAMCAVALLI](../CLAUDE.md). Questa e' la cartella del **codice**: sito, social e Meta Ads sono progetti separati accanto a questo. Per il codice comanda questo file, non quello del workspace.
+>
+> **Per i testi che legge un cliente** — etichette di stato, pulsanti, messaggi di errore, email transazionali — vale [`../brand/voce.md`](../brand/voce.md) e la regola in `../.claude/rules/lingua-e-tono.md`. Italiano, registro premium e assertivo, e nessun numero affermato che non stia in `../brand/prove.md`.
+
 Portale clienti per consulente di personal branding. Admin area + dashboard cliente via link segreto.
 
 ## Stack
@@ -50,7 +54,14 @@ Single source of truth: **`design-reference/DESIGN-SYSTEM.md`** ("Quiet Luxury"
 - Reuse the existing primitives before building new ones: `StatusBadge`, `SearchInput`, `SegmentedToggle`, `editable-cell`, `option-select`/`option-multi-select` in `src/components/ui/`, and the shell in `src/components/admin/AdminShell.tsx`.
 - Status/semantic colours (lead stages in `StatusBadge`) are the one sanctioned exception to the token rule — they use the Tailwind palette directly, each with an explicit `dark:` variant. So is the sidebar's brand green, and `src/lib/mailer.ts` (email HTML can't use CSS vars).
 
-Other docs: `STATUS.md` — **the single narrative document**: current status, backlog, and the operational lessons worth re-reading · `.planning/STATE.md` (GSD digest, kept under 100 lines, milestone v2.4) · `.planning/REQUIREMENTS.md` (current backlog) · `.planning/security/` (2026-07 audit, closed) · `.planning/milestones/` (closed-milestone archives).
+Other docs: `STATUS.md` — **the single narrative document**: current status, backlog, and the operational lessons worth re-reading · `.planning/STATE.md` (GSD digest, kept under 100 lines, milestone v2.4) · `.planning/REQUIREMENTS.md` (current backlog) · `.planning/security/` (2026-07 audit, closed) · `.planning/milestones/` (closed-milestone archives) · `.claude/CLAUDE.md` (guida della cartella di configurazione: skill, hook, dove sta la memoria) · `.claude/plans/` (i piani delle milestone).
+
+## Project Skills
+Due skill locali, in `.claude/skills/` (le altre sono globali in `~/.claude/skills/`):
+- **`/preventivo`** — la catena `agent.ts → schema.ts → assemble.ts → ProposalDeck` e come non spezzarla; preflight sui dati placeholder di `profile.ts`.
+- **`/audit`** — `npx tsx scripts/audit-fonti.ts <url>` mette in moto le cinque fonti di `src/lib/audit/sources/` (oggi inerti in prod) e dice cosa e' stato misurato.
+
+Due hook di guardia in `.claude/hooks/`: `guardia-migration.sh` **blocca** l'SQL distruttivo sulle entita' protette (Data Safety LOCKED), `guardia-token.sh` **avvisa** sulle classi Tailwind grezze. Dettaglio e comandi di prova in `.claude/CLAUDE.md`.
 
 ## GSD Workflow
 Planning in `.planning/`. Use `/gsd-plan-phase N` → `/gsd-execute-phase N`. State in `.planning/STATE.md`.

STATUS.md

@@ -30,7 +30,7 @@ schema dell'audit, nessuna pagina. La pausa è una scelta del 2026-08-19 — pri
 ### Modifiche hub (richieste 2026-08-18)
 
 Tre aree: dashboard, progetti, pipeline. Piano in
-`~/.claude/plans/sei-arrivato-qua-search-recursive-kettle.md`, **fuori dal repo**.
+[`.claude/plans/v2.5-modifiche-hub.md`](.claude/plans/v2.5-modifiche-hub.md).
 
 **In produzione dal 2026-08-19** (commit `4b135ce` → `19ed377`):
 
@@ -303,6 +303,159 @@ e «In revisione» (2) convivono, su 11 task, quindi l'unica dove si vede se ora
 distinguono davvero. Da guardare anche col tema scuro: è lì che l'icona «In corso» prima
 non aveva varianti.
 
+### Task cancellati e date dei pagamenti (2026-08-22)
+
+Due buchi che si vedevano solo aprendo il portale dalla parte del cliente.
+
+**Un task tolto dal lavoro non aveva dove stare.** L'admin poteva solo cancellarlo dal DB
+— e allora il cliente non capiva perché una voce che aveva letto la settimana prima non
+c'era più — oppure lasciarlo lì a fingersi «Da fare» per sempre. Ora `cancelled` è il
+quinto stato: **X dentro il cerchio, titolo barrato**, e la pill «Cancellata».
+
+È l'unico stato *chiuso* che porta la pill, e non è un'incoerenza: «Fatto» e «Cancellata»
+sono **entrambi barrati**, e scambiarli significa credere consegnato qualcosa che non
+esiste. La forma da sola non basta a coprire quel rischio.
+
+Il lavoro vero, di nuovo, non era il nuovo stato ma i denominatori. Un task cancellato esce
+da **tutti**: percentuale di fase, percentuale globale, board delle consegne, riepilogo
+admin — attraverso un solo `countsTowardProgress()` in `src/lib/task-status.ts`, non cinque
+`!== "cancelled"` sparsi in giro. Contarlo terrebbe la fase sotto il 100% per un lavoro che
+nessuno farà mai; contarlo come fatto racconterebbe una consegna mai avvenuta.
+`recomputePhaseStatus` lo ignora allo stesso modo: senza, cancellare l'ultima voce di una
+fase la lasciava «In corso» per sempre. Se restano **solo** cancellati la fase torna «Da
+iniziare» — è degenere, ma «Completata» al cliente racconterebbe una consegna che non c'è
+stata.
+
+Nel Kanban cliente la colonna «Cancellate» compare **solo se ha dentro qualcosa**, così le
+quattro che raccontano il lavoro si tengono la larghezza — ma mai se è piena, quindi nessun
+task sparisce dalla board: era esattamente il bug che aveva fatto nascere `TASK_STATUSES`.
+Nell'admin la colonna c'è sempre, ed è così che si cancella un task: trascinandocelo.
+
+**Il box pagamenti non sapeva dire quando si paga.** `payments` aveva `paid_at` — quando una
+rata è stata incassata — e nient'altro: nessun campo per la scadenza. Il portale non poteva
+rispondere alla domanda più ovvia del cliente, e non c'era niente su cui agganciare il
+promemoria via email. **Migration `0023`**, additiva: `payments.due_date`, nullable senza
+default, più un indice parziale su cui girerà la query del promemoria («le non saldate in
+scadenza entro N giorni», che l'indice `(project_id, sort_order)` non copre).
+
+Nullable è una scelta: una rata senza data concordata è normale, e un default inventerebbe
+una scadenza che nessuno ha pattuito. **Il portale mostra la data solo se c'è.**
+
+Cosa vede il cliente:
+
+- In cima al box, **«Prossimo pagamento»**: data lunga e conto alla rovescia in parole —
+  «tra 12 giorni», «domani», «oggi». Se è passata, il riquadro diventa rosso e dice
+  «Pagamento scaduto — scaduto da 3 giorni». Un arretrato batte sempre la rata del mese
+  prossimo: se c'è, *quello* è il prossimo pagamento.
+- Su ogni riga, la sua data: **«Scade il…»** se aperta, **«Pagato il…»** se saldata.
+- **Nessun importo per riga.** LOCKED #2 resta dov'era: le date non sono cifre.
+
+I giorni si contano in `src/lib/payment-dates.ts`, sui **giorni civili a Roma** e non sugli
+istanti: il container gira a UTC, e «manca una settimana» non deve cambiare risposta a
+seconda del fuso di chi renderizza. È lo stesso modulo che userà il promemoria email —
+scritto ora proprio perché la mail e il portale non si contraddicano su quanti giorni
+mancano. Le date si salvano a **mezzogiorno UTC**, non a mezzanotte: a mezzanotte UTC il
+giorno civile a Roma è già quello dopo, e la data tornerebbe indietro di un giorno appena
+riletta.
+
+Lato admin ogni rata ha ora il campo **Scadenza**, e «Incassato nel mese» è diventato
+**«Incassato il»** — precisione al giorno, che le analytics non notano perché raggruppano
+con `extract(month from paid_at)`. Il warning sul cambio schema rate conta anche le
+scadenze: una rata «da saldare» con una data è già sotto gli occhi del cliente, e
+sparirebbe in silenzio.
+
+**In produzione dal 2026-08-22** (`fe76789`). Migration `0023` applicata a prod **prima**
+del push, come da procedura: `ALTER TABLE` + `CREATE INDEX`, 12 righe in tabella, nessuna
+toccata. Build, typecheck e lint verdi — lint invariato, nessun problema nuovo nei file
+toccati.
+
+⚠️ **Due cose da fare a mano.** (1) Il portale non l'ho visto a schermo: vale la stessa
+verifica `?preview=1` della sezione precedente, e finché nessuna rata ha una `due_date` il
+riquadro «Prossimo pagamento» **non compare per definizione** — va messa una scadenza dal
+tab Pagamenti per vederlo. (2) Due `paid_at` storici valgono il **primo del mese**
+(2026-03-01 e 2026-01-01): li ha scritti così il vecchio selettore a mese, e ora il cliente
+li legge come «Pagato il 1 mar 2026». Se il giorno vero era un altro, si corregge dal nuovo
+campo.
+
+### Architettura `.claude/` (2026-08-26)
+
+Configurazione, non prodotto: l'unico file di codice che nasce qui è `scripts/audit-fonti.ts`.
+
+`hub/.claude/` aveva tre cose dentro — `rules/`, `settings.json`, `settings.local.json` — e
+nessun posto dove mettere una skill, un hook o un piano. Ora ha lo scheletro completo e un
+**`.claude/CLAUDE.md`** che spiega cosa va dove. Non è «il CLAUDE.md che mancava»: quello di
+progetto sta alla radice ed è lui a comandare. Questo è la guida della cartella di
+configurazione, e si carica quando ci lavori dentro.
+
+**Due skill locali** (le altre restano globali in `~/.claude/skills/`, e copiarle qui
+significherebbe averne due destinate a divergere):
+
+- **`/preventivo`** — non contiene un prompt di generazione, e non deve averlo: quello vive
+  in `agent.ts` ed è l'unico. Contiene la mappa della catena `agent.ts → schema.ts →
+  assemble.ts → ProposalDeck + sections/`, con la tabella dei tre modi di romperla — e solo
+  uno fa rumore. Campo nello schema e non nel prompt: **ogni** generazione muore con
+  «Contenuto AI non valido». Campo nel prompt e non nello schema: Zod lo scarta in silenzio.
+  Campo nello schema senza sezione che lo legge: generazione verde, sezione assente.
+  Porta anche `check-profilo.sh`, il preflight sui dati finti.
+- **`/audit`** — guida `scripts/audit-fonti.ts`, nuovo, che mette in moto le cinque fonti di
+  `src/lib/audit/sources/`, in produzione dal 2026-08-19 ma **mai chiamate da nessuno**.
+  Provate su giojello.com il 2026-08-26: cinque su cinque, **42,7 s** (PageSpeed 34,2), tre
+  pagine raccolte, CrUX disponibile a livello URL, PageSpeed mobile 58 / desktop 93. Il
+  grezzo finisce in `audit-fonti-<dominio>.json`, gitignorato: è lì che ogni numero del
+  documento dovrà essere rintracciabile. Distinto da `spike-audit.ts`, che è un altro
+  attrezzo e risponde a un'altra domanda.
+
+**Due hook di guardia**, provati a mano prima di fidarsene (6 casi il primo, 5 il secondo):
+
+- `guardia-migration.sh` **blocca** — è il vincolo Data Safety (LOCKED) fatto rispettare dalla
+  macchina invece che dalla memoria. Toglie i commenti e spezza per `;` prima di guardare, così
+  «non fare mai DROP TABLE payments» dentro un commento non fa scattare nulla, e
+  `ALTER TABLE clients DROP COLUMN token` sì. Fuori da `src/db/migrations/` non ha voce.
+- `guardia-token.sh` **avvisa e basta**. Bloccare, con ~450 occorrenze di debito già in casa,
+  lo renderebbe un ostacolo da disattivare invece di un promemoria da leggere. Whitelist per
+  le eccezioni sanzionate: `StatusBadge`, `AdminShell`, `mailer`, `globals.css`,
+  `design-reference/`.
+
+**I tre piani della milestone sono entrati nel repo.** Stavano solo in `~/.claude/plans/` con
+nomi generati a caso, e STATE.md avvertiva che senza quelli v2.5 non era ricostruibile: un
+piano che vive sul portatile di chi l'ha scritto non è documentazione, è un ricordo. Passati
+al setaccio per credenziali prima di committarli — dentro ci sono nomi di variabili
+d'ambiente, mai i loro valori.
+
+Corretta anche una riga di `rules/memory-discipline.md` che mandava nel posto sbagliato: la
+memoria persistente di hub sta sotto la chiave `…-Vault-IAMCAVALLI-hub`, non quella del
+workspace senza suffisso. Sedici file erano nella prima, la regola indicava la seconda.
+
+#### Due cose trovate sul preventivo, e non risolte
+
+Nessuna delle due è stata toccata: sono decisioni, non refusi.
+
+**`profile.ts` spedisce dati placeholder in ogni preventivo generato.** Tre testimonianze sono
+letteralmente `{ name: "Cliente 1", quote: "→ Aggiungere testimonianza reale." }`; accanto,
+email `simone@iamcavalli.com` e sito `iamcavalli.com` quando il dominio è **iamcavalli.net**, e
+titolo «Strategist · Brand & Business» quando il posizionamento è **Full Stack Designer**. Il
+file è uno **snapshot**: finisce in `proposals.content` al momento della generazione e ci resta
+anche correggendo il file dopo. Non è riempibile a occhio — `brand/prove.md` è ancora
+`stato: scheletro-intervista`, con i numeri marcati «da verificare». Quindi la mossa non è
+inventare: è **non renderizzare il blocco** finché il dato non c'è, allineare i campi già
+verificati, e portare la domanda a chi ha le testimonianze vere. `check-profilo.sh` oggi
+fallisce con 19 occorrenze, ed è il comportamento giusto.
+
+**`unitPrice` viaggia nel payload RSC di `/preventivo/[slug]`.** `PricingSection` renderizza
+solo `publicPrice ?? servicesTotal` e il nome dei servizi — corretto. Ma `assembleProposal`
+mette in `content.offer.tiers[].services[].unitPrice` anche il prezzo unitario, e
+`ProposalDeck` è `"use client"`: riceve l'intero `proposal` come prop da un server component,
+quindi tutto l'oggetto viene serializzato nella pagina, renderizzato o no. È la stessa trappola
+del gate OTP: **sparire a schermo non è sparire**. Verificato leggendo il codice, **non ancora
+a schermo** — serve `curl` su un preventivo pubblicato e `LC_ALL=C grep -c unitPrice`. Se
+conferma, la correzione è una proiezione client-safe come già fa `client-view.ts` per il
+portale, non nascondere una sezione.
+
+Terza, minore: `agent.ts` chiama il modello con `max_tokens: 8192` per uno schema che chiede
+fino a 5 problemi + 5 soluzioni + matrice. Se la risposta viene troncata l'errore non dice
+«troncata», dice «L'AI ha prodotto JSON non valido» — e manda a cercare nel posto sbagliato.
+Il controllo di `stop_reason` costa tre righe.
+
 ### v2.5 — Audit (Phases 27–30), in pausa
 
 Il servizio di analisi sito (tre livelli: **Radiografia / Prima-Dopo / Rotta**) diventa
@@ -323,9 +476,11 @@ Manca: agent + sintetizzatore + pipeline, storage immagini, editor admin, pagina
 pubblica. Dettaglio in [`.planning/ROADMAP.md`](.planning/ROADMAP.md) e
 [`.planning/REQUIREMENTS.md`](.planning/REQUIREMENTS.md).
 
-⚠️ **I due piani della milestone stanno in `~/.claude/plans/`, fuori dal repo**
-(`…woolly-puddle.md` per il documento, `…radiant-valley.md` per il motore). Senza quei
-file la milestone non è ricostruibile.
+I due piani della milestone sono **nel repo dal 2026-08-26**:
+[`.claude/plans/v2.5-audit-documento.md`](.claude/plans/v2.5-audit-documento.md) per il
+documento, [`.claude/plans/v2.5-audit-motore.md`](.claude/plans/v2.5-audit-motore.md) per il
+motore. Prima stavano solo in `~/.claude/plans/`, e senza quei file la milestone non era
+ricostruibile: un piano che vive sul portatile di chi l'ha scritto non è documentazione.
 
 ## Fatto
 

design-reference/DESIGN-SYSTEM.md

@@ -389,16 +389,32 @@ The `/client/[token]` portal was migrated to the same "Quiet Luxury" tokens
   `bg-muted`/`text-muted-foreground` (upcoming) — each with a `dark:` variant.
 - **Phase cards** (`PhaseCard`): `rounded-xl border-border-light bg-card
   shadow-card`, progress bar colored per status (emerald/amber/`bg-border`).
-- **Stato dei task** (`TaskStatusIndicator`): le quattro forme si distinguono
+- **Stato dei task** (`TaskStatusIndicator`): le cinque forme si distinguono
   **senza colore** — `todo` cerchio vuoto `border-border`, `in_progress` cerchio +
   punto ambra, `in_review` cerchio + **spunta vuota** violetta, `done` cerchio pieno
-  + spunta emerald. La spunta compare a lavoro finito e si riempie a lavoro confermato.
-  La pill di testo compare **solo** su `in_progress` e `in_review`; `todo` e `done` si
-  leggono dalla forma e dal titolo barrato. Colori come le altre pill del portale (soft
-  tint `-50/700` + variante `dark:`), tutti raccolti in `TASK_STATUS_VISUALS` e mai
-  riscritti nei componenti: le stesse tinte colorano le colonne del Kanban cliente e la
-  legenda, che si genera da `TASK_STATUSES`. L'icona è `aria-hidden` e lo stato viaggia
-  in uno `sr-only`, così lo screen reader lo annuncia anche sui due senza pill.
+  + spunta emerald, `cancelled` cerchio spento + **X**. La spunta compare a lavoro
+  finito e si riempie a lavoro confermato; la X è l'unica forma che non è un passo
+  avanti. La pill di testo compare su `in_progress`, `in_review` e `cancelled`;
+  `todo` e `done` si leggono dalla forma e dal titolo. **`done` e `cancelled` sono
+  entrambi barrati**, ed è proprio per questo che `cancelled` porta la pill: la
+  differenza fra consegnato e tolto dal lavoro è troppo importante per affidarla al
+  solo disegno dentro il cerchio. Colori come le altre pill del portale (soft tint
+  `-50/700` + variante `dark:`, tinta `muted` per la cancellata), tutti raccolti in
+  `TASK_STATUS_VISUALS` e mai riscritti nei componenti: le stesse tinte colorano le
+  colonne del Kanban cliente e la legenda, che si genera da `TASK_STATUSES`. L'icona
+  è `aria-hidden` e lo stato viaggia in uno `sr-only`, così lo screen reader lo
+  annuncia anche su quelli senza pill.
+  La colonna «Cancellate» del Kanban cliente è l'unica che **si nasconde da vuota**
+  (le altre quattro si tengono la larghezza) — mai se è piena: nessun task deve
+  sparire dalla board.
+- **Box pagamenti** (`PaymentStatus`): sopra le righe, un riquadro «Prossimo
+  pagamento» con data lunga e conto alla rovescia in parole («tra 12 giorni»,
+  «domani», «oggi»); se la scadenza è passata diventa rosso e dice «Pagamento
+  scaduto — scaduto da N giorni». Ogni riga porta la sua data sotto l'etichetta:
+  «Scade il…» se aperta, «Pagato il…» se saldata, **nulla** se in gestionale la data
+  non c'è — il portale non inventa scadenze. Nessun importo per riga (LOCKED #2):
+  le date non sono cifre. I giorni si contano in `src/lib/payment-dates.ts` sui
+  giorni civili a Roma, non sugli istanti.
 - Sidebar cards (`OffersSection`, `PaymentStatus`, `DocumentsSection`,
   `NotesSection`, `TranscriptsSection`) all follow `rounded-xl border-border-light
   bg-card shadow-card`.

scripts/audit-fonti.ts

@@ -0,0 +1,108 @@
+/**
+ * Mette in moto le cinque fonti di `src/lib/audit/sources/` su un URL.
+ *
+ * Le fonti sono in produzione dal 2026-08-19 ma INERTI: nessuna route le chiama.
+ * Questo script e' l'unico modo di vederle funzionare, e serve a rispondere a una
+ * domanda sola: **cosa e' stato misurato davvero, e cosa no.** Un buco qui e' il
+ * risultato, non un errore da nascondere — il motore dovra' saperlo dire al cliente.
+ *
+ * Nessun LLM, nessun database, nessun browser headless (il VPS non lo regge).
+ *
+ *   npx tsx scripts/audit-fonti.ts https://esempio.it
+ *   npx tsx scripts/audit-fonti.ts https://esempio.it --profilo=ecommerce
+ *   npx tsx scripts/audit-fonti.ts https://esempio.it --no-psi
+ *
+ * PAGESPEED_API_KEY (per PageSpeed e CrUX) viene letta dall'ambiente o da .env.local.
+ */
+import { readFileSync, writeFileSync, existsSync } from "node:fs";
+import { resolve } from "node:path";
+import { raccogliPagine } from "../src/lib/audit/sources/fetch";
+import { rilevaCrux } from "../src/lib/audit/sources/crux";
+import { rilevaPagespeedCompleto } from "../src/lib/audit/sources/pagespeed";
+import { rilevaStorico } from "../src/lib/audit/sources/history";
+import { rilevaSegnali } from "../src/lib/audit/sources/signals";
+
+function caricaEnv() {
+  if (process.env.PAGESPEED_API_KEY) return;
+  const f = resolve(process.cwd(), ".env.local");
+  if (!existsSync(f)) return;
+  for (const riga of readFileSync(f, "utf8").split("\n")) {
+    const m = riga.match(/^\s*(?:export\s+)?([A-Z0-9_]+)\s*=\s*(.*)$/);
+    if (m && !process.env[m[1]]) process.env[m[1]] = m[2].trim().replace(/^["']|["']$/g, "");
+  }
+}
+
+/** Esegue una fonte senza far cadere le altre: un buco e' un dato, non un crash. */
+async function fonte<T>(nome: string, f: () => Promise<T>) {
+  const t0 = Date.now();
+  try {
+    const dati = await f();
+    return { nome, ok: true as const, ms: Date.now() - t0, dati };
+  } catch (e) {
+    const msg = e instanceof Error ? e.message : String(e);
+    return { nome, ok: false as const, ms: Date.now() - t0, errore: msg };
+  }
+}
+
+async function main() {
+  caricaEnv();
+
+  const argv = process.argv.slice(2);
+  const url = argv.find((a) => !a.startsWith("--"));
+  if (!url) {
+    console.error("uso: npx tsx scripts/audit-fonti.ts <url> [--profilo=servizi] [--no-psi]");
+    process.exit(1);
+  }
+  const profilo = argv.find((a) => a.startsWith("--profilo="))?.split("=")[1] ?? "servizi";
+  const psi = !argv.includes("--no-psi");
+  const inizio = Date.now();
+
+  console.log(`\n  ${url}  ·  profilo ${profilo}${psi ? "" : "  ·  PageSpeed saltato"}`);
+  if (!process.env.PAGESPEED_API_KEY) {
+    console.log("  ⚠ PAGESPEED_API_KEY assente: PageSpeed e CrUX risponderanno a vuoto.");
+  }
+  console.log("");
+
+  // La home serve alle altre due fonti: si scarica una volta sola.
+  const raccolta = await fonte("pagine", () => raccogliPagine(url, profilo));
+  if (!raccolta.ok) {
+    console.error(`  ✗ pagine — ${raccolta.errore}\n\n  Senza la home non parte nient'altro.`);
+    process.exit(1);
+  }
+  const { home, homeHtml, homeHeaders, pagine, errori } = raccolta.dati;
+
+  const risultati = [
+    raccolta,
+    ...(await Promise.all([
+      fonte("crux", () => rilevaCrux(home)),
+      ...(psi ? [fonte("pagespeed", () => rilevaPagespeedCompleto(home))] : []),
+      fonte("storico", () => rilevaStorico(home, homeHtml)),
+      fonte("segnali", () => rilevaSegnali(home, homeHtml, homeHeaders)),
+    ])),
+  ];
+
+  console.log("  FONTE       ESITO   TEMPO");
+  for (const r of risultati) {
+    const esito = r.ok ? "ok    " : "MUTA  ";
+    console.log(`  ${r.nome.padEnd(11)} ${esito}  ${(r.ms / 1000).toFixed(1)}s${r.ok ? "" : `   ${r.errore}`}`);
+  }
+
+  console.log(`\n  Pagine raccolte: ${pagine.length} (${pagine.map((p) => p.ruolo).join(", ")})`);
+  if (errori.length) console.log(`  Non scaricate:   ${errori.join(", ")}`);
+  if (home !== url) console.log(`  Canonico:        ${home}  (redirect dal valore passato)`);
+
+  // Il grezzo e' il posto dove ogni numero del documento dovra' essere rintracciabile.
+  const dominio = new URL(home).hostname.replace(/^www\./, "");
+  const file = resolve(process.cwd(), `audit-fonti-${dominio}.json`);
+  writeFileSync(file, JSON.stringify({ url: home, profilo, quando: new Date().toISOString(), risultati }, null, 2));
+
+  console.log(`\n  Grezzo: ${file}`);
+  console.log(`  Totale: ${((Date.now() - inizio) / 1000).toFixed(1)}s\n`);
+  console.log("  Un numero entra in un documento solo se lo ritrovi qui dentro.");
+  console.log("  Un punteggio PageSpeed va sempre con la sua data: ballano di 12 punti in mezz'ora.\n");
+}
+
+main().catch((e) => {
+  console.error("\nERRORE:", e instanceof Error ? e.message : e);
+  process.exit(1);
+});

src/app/admin/clients/[id]/actions.ts

@@ -23,7 +23,7 @@ import {
 } from "@/db/schema";
 import { eq, asc, and, isNull } from "drizzle-orm";
 import { z } from "zod";
-import { isTaskStatus } from "@/lib/task-status";
+import { countsTowardProgress, isTaskStatus } from "@/lib/task-status";
 
 // ── ENTITY RESOLUTION ────────────────────────────────────────────────────────
 // Both clientId and projectId are passed as "clientId" by tab components.
@@ -187,16 +187,24 @@ export async function addTask(phaseId: string, id: string, formData: FormData) {
 // that count as started: as a list it silently forgot new statuses, and a phase
 // whose tasks were all in review fell back to "upcoming" — reading as
 // not-started when it was nearly finished.
+//
+// I task cancellati sono invisibili a questo calcolo: non tengono la fase aperta
+// (senza questo, cancellare l'ultima voce la lascerebbe "in corso" per sempre) e
+// da soli non la fanno partire. Se restano SOLO cancellati la fase torna
+// "Da iniziare": è degenere, ma è meglio di "Completata", che al cliente
+// racconterebbe una consegna che non c'è stata.
 export async function recomputePhaseStatus(phaseId: string): Promise<void> {
   const phaseTasks = await db
     .select({ status: tasks.status })
     .from(tasks)
     .where(eq(tasks.phase_id, phaseId));
 
+  const countedTasks = phaseTasks.filter((t) => countsTowardProgress(t.status));
+
   let newStatus: "upcoming" | "active" | "done" = "upcoming";
-  if (phaseTasks.length > 0) {
-    const allDone = phaseTasks.every((t) => t.status === "done");
-    const anyActive = phaseTasks.some((t) => t.status !== "todo");
+  if (countedTasks.length > 0) {
+    const allDone = countedTasks.every((t) => t.status === "done");
+    const anyActive = countedTasks.some((t) => t.status !== "todo");
     if (allDone) newStatus = "done";
     else if (anyActive) newStatus = "active";
   }
@@ -326,17 +334,42 @@ export async function updatePaymentStatus(paymentId: string, id: string, status:
   revalidatePath(path);
 }
 
-// Imposta il mese in cui un pagamento è stato incassato (formato "YYYY-MM").
-// Mappa al primo giorno del mese (mezzogiorno UTC per evitare drift di fuso) e
-// porta lo stato a "saldato" così l'incasso viene attribuito a quel mese nelle analytics.
-export async function setPaymentPaidAt(paymentId: string, id: string, monthStr: string) {
+// Parsing di una data inserita dall'admin, in due formati:
+//   "YYYY-MM-DD" → quel giorno       (quello che scrivono i campi di oggi)
+//   "YYYY-MM"    → primo del mese    (formato storico di paid_at, campo <input type="month">)
+//
+// Mezzogiorno UTC, non mezzanotte: a mezzanotte UTC il giorno civile a Roma è già
+// quello dopo per due ore in estate, e la data tornerebbe indietro di un giorno
+// una volta riletta. A mezzogiorno nessun fuso reale sposta il giorno.
+function parseAdminDate(value: string): Date {
+  const day = /^(\d{4})-(\d{2})-(\d{2})$/.exec(value);
+  if (day) {
+    const [, y, m, d] = day;
+    const year = parseInt(y, 10);
+    const month = parseInt(m, 10);
+    const date = parseInt(d, 10);
+    if (month < 1 || month > 12 || date < 1 || date > 31) throw new Error("Data non valida");
+    return new Date(Date.UTC(year, month - 1, date, 12, 0, 0));
+  }
+
+  const month = /^(\d{4})-(\d{2})$/.exec(value);
+  if (month) {
+    const [, y, m] = month;
+    const monthNum = parseInt(m, 10);
+    if (monthNum < 1 || monthNum > 12) throw new Error("Data non valida");
+    return new Date(Date.UTC(parseInt(y, 10), monthNum - 1, 1, 12, 0, 0));
+  }
+
+  throw new Error("Data non valida");
+}
+
+// Imposta il giorno in cui un pagamento è stato incassato e porta lo stato a
+// "saldato", così l'incasso viene attribuito a quel mese nelle analytics (che
+// raggruppano con `extract(month from paid_at)`: la precisione al giorno non le
+// tocca). Accetta anche il vecchio "YYYY-MM" delle righe storiche.
+export async function setPaymentPaidAt(paymentId: string, id: string, dateStr: string) {
   await requireAdmin();
-  const m = /^(\d{4})-(\d{2})$/.exec(monthStr);
-  if (!m) throw new Error("Mese non valido");
-  const year = parseInt(m[1], 10);
-  const month = parseInt(m[2], 10);
-  if (month < 1 || month > 12) throw new Error("Mese non valido");
-  const paid_at = new Date(Date.UTC(year, month - 1, 1, 12, 0, 0));
+  const paid_at = parseAdminDate(dateStr);
   await db
     .update(payments)
     .set({ paid_at, status: "saldato" })
@@ -345,6 +378,17 @@ export async function setPaymentPaidAt(paymentId: string, id: string, monthStr:
   revalidatePath(path);
 }
 
+// Scadenza concordata della rata. Stringa vuota = la scadenza si toglie: era
+// stata messa e non vale più, e cancellarla deve essere possibile senza dover
+// cancellare la rata.
+export async function setPaymentDueDate(paymentId: string, id: string, dateStr: string) {
+  await requireAdmin();
+  const due_date = dateStr.trim() === "" ? null : parseAdminDate(dateStr);
+  await db.update(payments).set({ due_date }).where(eq(payments.id, paymentId));
+  const { path } = await resolveEntity(id);
+  revalidatePath(path);
+}
+
 // Rescales payment amounts when the total changes.
 //
 // The rule is PER ROW, not per project. The previous version decided with

src/app/admin/conversazioni/actions.ts

@@ -8,6 +8,8 @@ import { authOptions } from "@/lib/auth";
 import { db } from "@/db";
 import { clients, comments } from "@/db/schema";
 import { assertClientOwnsEntity } from "@/lib/client-chat";
+import { hasMention, mentionCandidates } from "@/lib/mentions";
+import { notifyClientMention } from "@/lib/client-notifications";
 
 async function requireAdmin() {
   const session = await getServerSession(authOptions);
@@ -43,12 +45,12 @@ export async function replyToConversation(clientId: string, formData: FormData)
   if (!clientId || !parsed.success) throw new Error("Dati mancanti");
   const { entity_type, entity_id, body } = parsed.data;
 
-  const rows = await db
-    .select({ id: clients.id })
+  const [client] = await db
+    .select({ id: clients.id, name: clients.name, brand_name: clients.brand_name })
     .from(clients)
     .where(eq(clients.id, clientId))
     .limit(1);
-  if (rows.length === 0) throw new Error("Cliente non trovato");
+  if (!client) throw new Error("Cliente non trovato");
 
   // Stessa verifica di appartenenza usata dalle route del portale: un entity_id
   // arbitrario nel form non deve poter scrivere nella chat di un altro cliente.
@@ -68,6 +70,17 @@ export async function replyToConversation(clientId: string, formData: FormData)
     .set({ admin_last_read_at: new Date() })
     .where(eq(clients.id, clientId));
 
+  // Il tag è l'unico messaggio che esce dal portale. Si valuta sul testo appena
+  // scritto, non su un campo nascosto del form: quello resterebbe indietro se
+  // l'admin cancellasse la menzione prima di inviare.
+  //
+  // L'invio non è dentro una transazione con l'insert e non deve esserlo: se la
+  // mail fallisce, il messaggio in chat resta comunque scritto — il contrario
+  // sarebbe perdere il messaggio per colpa del provider di posta.
+  if (hasMention(body, mentionCandidates(client))) {
+    await notifyClientMention({ clientId, channelKey: entity_id, body });
+  }
+
   revalidatePath("/admin/conversazioni");
   revalidatePath(`/admin/clients/${clientId}`);
 }

src/app/client/[token]/page.tsx

@@ -58,6 +58,8 @@ function projectViewToClientView(
       id: p.id,
       label: p.label,
       status: p.status as "da_saldare" | "inviata" | "saldato",
+      due_date: p.due_date instanceof Date ? p.due_date.toISOString() : null,
+      paid_at: p.paid_at instanceof Date ? p.paid_at.toISOString() : null,
     })),
     documents: view.documents.map((d) => ({
       id: d.id,
@@ -96,15 +98,31 @@ export async function generateMetadata({
   };
 }
 
+/**
+ * Il canale chiesto con `?chat=<key>`, se appartiene a QUESTO progetto.
+ *
+ * La validazione non e' cosmetica: senza, un id qualsiasi nella query aprirebbe
+ * la chat su un canale vuoto — e con piu' progetti a tab, la fase di un progetto
+ * spalancherebbe il pannello anche negli altri.
+ */
+function resolveChatChannel(
+  requested: string | undefined,
+  view: ProjectView
+): string | null {
+  if (!requested) return null;
+  if (requested === view.project.client_id) return requested;
+  return view.phases.some((p) => p.id === requested) ? requested : null;
+}
+
 export default async function ClientPage({
   params,
   searchParams,
 }: {
   params: Promise<{ token: string }>;
-  searchParams: Promise<{ preview?: string }>;
+  searchParams: Promise<{ preview?: string; chat?: string }>;
 }) {
   const { token } = await params;
-  const { preview: previewParam } = await searchParams;
+  const { preview: previewParam, chat: chatParam } = await searchParams;
 
   // ⚠️ Il gate va PRIMA di ogni query sui dati del progetto: se si interroga il
   // DB e poi si decide di mostrare il form, i dati sono già nel payload RSC
@@ -159,6 +177,7 @@ export default async function ClientPage({
             adminAvatarUrl: admin.avatarUrl,
           }}
           preview={preview}
+          initialChatChannel={resolveChatChannel(chatParam, view)}
         />
       </>
     );
@@ -212,6 +231,7 @@ export default async function ClientPage({
                     }}
                     embedded
                     preview={preview}
+                    initialChatChannel={resolveChatChannel(chatParam, view)}
                   />
                 ) : (
                   <p className="text-sm text-muted-foreground">Progetto non disponibile.</p>

src/components/admin/ProjectSummary.tsx

@@ -1,5 +1,6 @@
 import { MetricCard, fmtEur0 } from "@/components/admin/MetricCard";
 import type { ProjectFullDetail } from "@/lib/admin-queries";
+import { countsTowardProgress } from "@/lib/task-status";
 
 type Props = {
   acceptedTotal: string;
@@ -38,7 +39,9 @@ export function ProjectSummary({
 
   const collectedPct = contracted > 0 ? Math.round((collected / contracted) * 100) : 0;
 
-  const allTasks = phases.flatMap((p) => p.tasks);
+  // Le cancellate escono dal denominatore, come nel portale cliente: le due
+  // percentuali devono raccontare la stessa cosa.
+  const allTasks = phases.flatMap((p) => p.tasks).filter((t) => countsTowardProgress(t.status));
   const doneTasks = allTasks.filter((t) => t.status === "done").length;
   const progressPct =
     allTasks.length > 0 ? Math.round((doneTasks / allTasks.length) * 100) : 0;

src/components/admin/conversazioni/ConversationsView.tsx

@@ -5,13 +5,13 @@ import Link from "next/link";
 import { useRouter } from "next/navigation";
 import { ExternalLink, IdCard, MessageSquare } from "lucide-react";
 import { SearchInput } from "@/components/ui/SearchInput";
-import { Button } from "@/components/ui/button";
 import { Textarea } from "@/components/ui/textarea";
+import { MentionText } from "@/components/ui/MentionText";
 import { cn } from "@/lib/utils";
+import { ReplyComposer } from "./ReplyComposer";
 import {
   editConversationMessage,
   markConversationRead,
-  replyToConversation,
 } from "@/app/admin/conversazioni/actions";
 import type {
   ConversationSummary,
@@ -93,7 +93,7 @@ export function ConversationsView({
         ) : (
           <div className="flex-1 flex flex-col items-center justify-center text-center gap-3 text-muted-foreground">
             <MessageSquare className="w-10 h-10 opacity-40" strokeWidth={1.5} />
-            <p className="text-sm">Nessun messaggio dai clienti ancora.</p>
+            <p className="text-sm">Scegli un cliente per aprire la conversazione.</p>
           </div>
         )}
       </section>
@@ -126,18 +126,28 @@ function ConversationListItem({
         >
           {conv.name}
         </span>
+        {conv.lastMessageAt && (
           <span className="text-[10px] font-mono text-muted-foreground shrink-0">
             {formatListTime(conv.lastMessageAt)}
           </span>
+        )}
       </div>
       <p className="mt-1 text-xs text-muted-foreground truncate">
+        {conv.lastMessageAt ? (
+          <>
             {conv.lastMessageAuthor === "admin" && (
               <span className="text-muted-foreground/70">Tu: </span>
             )}
             {conv.lastMessage}
+          </>
+        ) : (
+          <span className="italic text-muted-foreground/70">
+            Nessun messaggio — scrivi tu per primo
+          </span>
+        )}
       </p>
       <div className="mt-2 flex items-center justify-between gap-2">
-        <EntityBadge label={conv.lastEntityLabel} />
+        {conv.lastMessageAt ? <EntityBadge label={conv.lastEntityLabel} /> : <span />}
         {conv.unread && (
           <span className="flex items-center gap-1.5 shrink-0">
             {conv.unreadCount > 1 && (
@@ -272,34 +282,29 @@ function ActiveThread({ thread }: { thread: ConversationThread }) {
       <div ref={scrollRef} className="flex-1 overflow-y-auto p-6 bg-muted/20 space-y-4">
         {visibleMessages.length === 0 ? (
           <p className="text-sm text-muted-foreground text-center py-10">
-            Nessun messaggio in questo canale.
+            Nessun messaggio in questo canale. Scrivi tu per primo.
           </p>
         ) : (
           visibleMessages.map((m) => (
-            <MessageBubble key={m.id} message={m} clientId={thread.clientId} />
+            <MessageBubble
+              key={m.id}
+              message={m}
+              clientId={thread.clientId}
+              mentionCandidates={thread.mentionAliases}
+            />
           ))
         )}
       </div>
 
       {/* Reply box — il canale viaggia col messaggio */}
-      <form
-        action={replyToConversation.bind(null, thread.clientId)}
-        className="p-4 border-t border-border bg-card flex items-end gap-3"
-      >
-        <input type="hidden" name="entity_type" value={isGeneral ? "general" : "phase"} />
-        <input type="hidden" name="entity_id" value={activeChannel} />
-        <Textarea
-          name="body"
-          rows={2}
-          required
-          placeholder={`Rispondi in ${activeLabel}...`}
-          aria-label={`Rispondi nel canale ${activeLabel}`}
-          className="flex-1 resize-none"
+      <ReplyComposer
+        clientId={thread.clientId}
+        channelKey={activeChannel}
+        channelLabel={activeLabel}
+        isGeneral={isGeneral}
+        mentionTargets={thread.mentionTargets}
+        notifyEmailCount={thread.notifyEmailCount}
       />
-        <Button type="submit" size="sm" className="shrink-0">
-          Invia
-        </Button>
-      </form>
     </>
   );
 }
@@ -307,9 +312,11 @@ function ActiveThread({ thread }: { thread: ConversationThread }) {
 function MessageBubble({
   message,
   clientId,
+  mentionCandidates,
 }: {
   message: ConversationThread["messages"][number];
   clientId: string;
+  mentionCandidates: string[];
 }) {
   const isAdmin = message.author === "admin";
   // Solo task e deliverable: per una fase l'etichetta ripeterebbe il tab attivo.
@@ -391,7 +398,17 @@ function MessageBubble({
             />
           ) : (
             <p className="text-xs leading-relaxed whitespace-pre-wrap">
-              {message.body}
+              <MentionText
+                body={message.body}
+                candidates={mentionCandidates}
+                // Sulla bolla admin il fondo è `bg-primary`: un chip tenue ci
+                // sparirebbe sopra, quindi si scava invece di colorare.
+                mentionClassName={
+                  isAdmin
+                    ? "rounded bg-primary-foreground/20 px-1 font-semibold"
+                    : undefined
+                }
+              />
             </p>
           )}
 

src/components/admin/conversazioni/ReplyComposer.tsx

@@ -0,0 +1,219 @@
+"use client";
+
+import { useMemo, useRef, useState, useTransition } from "react";
+import { AtSign } from "lucide-react";
+import { Button } from "@/components/ui/button";
+import { Textarea } from "@/components/ui/textarea";
+import { cn } from "@/lib/utils";
+import { normalizeForSearch, type MentionTarget } from "@/lib/mentions";
+import { replyToConversation } from "@/app/admin/conversazioni/actions";
+
+/**
+ * Casella di risposta dell'inbox, con il tag del cliente.
+ *
+ * È controllata — e non più un `<form action>` con una textarea libera — perché
+ * il suggerimento del tag deve leggere il testo mentre lo scrivi e riscriverlo
+ * al punto giusto. Il canale continua a viaggiare col messaggio: `entity_id` è
+ * il canale aperto, `entity_type` si deriva da esso.
+ */
+export function ReplyComposer({
+  clientId,
+  channelKey,
+  channelLabel,
+  isGeneral,
+  mentionTargets,
+  notifyEmailCount,
+}: {
+  clientId: string;
+  channelKey: string;
+  channelLabel: string;
+  isGeneral: boolean;
+  /**
+   * Chi si può taggare: **una voce per destinatario**, non una per modo di
+   * scriverlo. Prima qui arrivava la lista piatta degli alias e il menu mostrava
+   * tre righe — nome, brand, nome di battesimo — per una persona sola.
+   */
+  mentionTargets: MentionTarget[];
+  /** Quante mail partirebbero davvero con un tag. Zero = si avvisa, non si tace. */
+  notifyEmailCount: number;
+}) {
+  const [body, setBody] = useState("");
+  const [error, setError] = useState<string | null>(null);
+  const [sending, startSending] = useTransition();
+  const textareaRef = useRef<HTMLTextAreaElement>(null);
+
+  // Posizione dell'ultima "@" ancora aperta e testo digitato dopo: null quando
+  // non c'è nessun tag in corso di scrittura.
+  const [trigger, setTrigger] = useState<{ at: number; query: string } | null>(null);
+
+  const suggestions = useMemo(() => {
+    if (!trigger) return [];
+    const q = normalizeForSearch(trigger.query);
+    // Si filtra sugli alias ma si tiene il TARGET: digitando «car» il cliente si
+    // trova passando dal brand, e resta comunque una riga sola col suo nome.
+    // La normalizzazione è quella del parser, così «nicolo» trova «Nicolò».
+    return mentionTargets
+      .filter((t) => t.aliases.some((a) => normalizeForSearch(a).startsWith(q)))
+      .slice(0, 6);
+  }, [trigger, mentionTargets]);
+
+  const open = suggestions.length > 0;
+
+  function syncTrigger(value: string, caret: number) {
+    const before = value.slice(0, caret);
+    const at = before.lastIndexOf("@");
+    if (at === -1) return setTrigger(null);
+    // Una "@" vale solo a inizio parola: "email@dominio.it" non apre il menu.
+    const prev = at > 0 ? before[at - 1] : " ";
+    if (!/\s/.test(prev)) return setTrigger(null);
+    const query = before.slice(at + 1);
+    // Un tag non attraversa un a capo, e oltre il nome più lungo non c'è più
+    // niente da suggerire.
+    if (query.includes("\n")) return setTrigger(null);
+    setTrigger({ at, query });
+  }
+
+  function insert(candidate: string) {
+    if (!trigger) return;
+    const el = textareaRef.current;
+    const caret = el?.selectionStart ?? body.length;
+    const next = `${body.slice(0, trigger.at)}@${candidate} ${body.slice(caret)}`;
+    const nextCaret = trigger.at + candidate.length + 2;
+    setBody(next);
+    setTrigger(null);
+    requestAnimationFrame(() => {
+      el?.focus();
+      el?.setSelectionRange(nextCaret, nextCaret);
+    });
+  }
+
+  /** Il pulsante @: inserisce la chiocciola e apre subito il menu. */
+  function startMention() {
+    const el = textareaRef.current;
+    const caret = el?.selectionStart ?? body.length;
+    const needsSpace = caret > 0 && !/\s/.test(body[caret - 1]);
+    const prefix = needsSpace ? " @" : "@";
+    const next = `${body.slice(0, caret)}${prefix}${body.slice(caret)}`;
+    const nextCaret = caret + prefix.length;
+    setBody(next);
+    setTrigger({ at: nextCaret - 1, query: "" });
+    requestAnimationFrame(() => {
+      el?.focus();
+      el?.setSelectionRange(nextCaret, nextCaret);
+    });
+  }
+
+  function send() {
+    const text = body.trim();
+    if (!text || sending) return;
+    const fd = new FormData();
+    fd.set("entity_type", isGeneral ? "general" : "phase");
+    fd.set("entity_id", channelKey);
+    fd.set("body", text);
+    setError(null);
+    startSending(async () => {
+      try {
+        await replyToConversation(clientId, fd);
+        setBody("");
+        setTrigger(null);
+      } catch {
+        setError("Messaggio non inviato, riprova");
+      }
+    });
+  }
+
+  return (
+    <div className="border-t border-border bg-card p-4">
+      <div className="relative flex items-end gap-3">
+        {open && (
+          <ul
+            role="listbox"
+            aria-label="Tagga il cliente"
+            className="absolute bottom-full left-0 z-20 mb-2 w-64 overflow-hidden rounded-lg border border-border bg-card shadow-lg"
+          >
+            {suggestions.map((target, i) => (
+              <li key={target.label}>
+                <button
+                  type="button"
+                  role="option"
+                  aria-selected={i === 0}
+                  // onMouseDown e non onClick: il click toglierebbe il fuoco alla
+                  // textarea prima di leggerne il caret, e l'inserimento finirebbe
+                  // nel posto sbagliato.
+                  onMouseDown={(e) => {
+                    e.preventDefault();
+                    insert(target.label);
+                  }}
+                  className={cn(
+                    "flex w-full items-center gap-2 px-3 py-2 text-left text-sm transition-colors hover:bg-muted",
+                    i === 0 && "bg-muted/50"
+                  )}
+                >
+                  <AtSign className="h-3.5 w-3.5 shrink-0 text-muted-foreground" />
+                  <span className="truncate font-medium text-foreground">{target.label}</span>
+                </button>
+              </li>
+            ))}
+          </ul>
+        )}
+
+        <Textarea
+          ref={textareaRef}
+          value={body}
+          onChange={(e) => {
+            setBody(e.target.value);
+            syncTrigger(e.target.value, e.target.selectionStart ?? e.target.value.length);
+          }}
+          onClick={(e) => {
+            const el = e.currentTarget;
+            syncTrigger(el.value, el.selectionStart ?? el.value.length);
+          }}
+          onKeyDown={(e) => {
+            if (open && (e.key === "Enter" || e.key === "Tab")) {
+              e.preventDefault();
+              insert(suggestions[0].label);
+              return;
+            }
+            if (e.key === "Escape" && open) {
+              e.preventDefault();
+              setTrigger(null);
+              return;
+            }
+            // Invio manda, Shift+Invio va a capo: il comportamento che il
+            // pannello del cliente ha già.
+            if (e.key === "Enter" && !e.shiftKey) {
+              e.preventDefault();
+              send();
+            }
+          }}
+          rows={2}
+          placeholder={`Rispondi in ${channelLabel}...`}
+          aria-label={`Rispondi nel canale ${channelLabel}`}
+          className="flex-1 resize-none"
+        />
+
+        <div className="flex shrink-0 flex-col items-end gap-2">
+          <Button type="button" size="sm" onClick={send} disabled={sending || !body.trim()}>
+            {sending ? "Invio…" : "Invia"}
+          </Button>
+        </div>
+      </div>
+
+      <div className="mt-2 flex flex-wrap items-center gap-3">
+        <button
+          type="button"
+          onClick={startMention}
+          className="inline-flex items-center gap-1 text-[11px] font-semibold text-muted-foreground transition-colors hover:text-foreground"
+        >
+          <AtSign className="h-3 w-3" /> Tagga
+        </button>
+        <span className="text-[11px] text-muted-foreground">
+          {notifyEmailCount > 0
+            ? `Un tag gli manda una mail (${notifyEmailCount} ${notifyEmailCount === 1 ? "indirizzo" : "indirizzi"}).`
+            : "Nessuna email a registro: il tag resta solo in chat."}
+        </span>
+        {error && <span className="text-[11px] text-destructive">{error}</span>}
+      </div>
+    </div>
+  );
+}

src/components/admin/dashboard/InboxBand.tsx

@@ -58,7 +58,10 @@ export async function InboxBand() {
                   {conv.brand_name}
                 </h3>
                 <span className="text-[10px] text-muted-foreground font-mono tabular-nums shrink-0">
-                  {relativeTime(conv.lastMessageAt)}
+                  {/* `unread` implica almeno un messaggio: il null non capita,
+                      ma il tipo lo ammette da quando la lista include anche i
+                      clienti con cui non si è ancora scritto. */}
+                  {conv.lastMessageAt ? relativeTime(conv.lastMessageAt) : ""}
                 </span>
                 {conv.unreadCount > 1 && (
                   <span className="text-[10px] font-bold text-emerald-700 dark:text-emerald-400 shrink-0">

src/components/admin/kanban/KanbanBoard.tsx

@@ -38,6 +38,7 @@ const COLUMN_STYLES: Record<Status, { headerClass: string; dotClass: string }> =
     dotClass: "bg-violet-500",
   },
   done: { headerClass: "text-[#1A463C]", dotClass: "bg-[#1A463C]" },
+  cancelled: { headerClass: "text-[#a1a1aa]", dotClass: "bg-[#a1a1aa]" },
 };
 
 const COLUMNS: { id: Status; label: string; headerClass: string; dotClass: string }[] =
@@ -92,6 +93,7 @@ function DroppableColumn({
             key={task.id}
             task={task}
             isActive={activeId === task.id}
+            status={id}
           />
         ))}
         {tasks.length === 0 && (
@@ -107,9 +109,11 @@ function DroppableColumn({
 function DraggableCard({
   task,
   isActive,
+  status,
 }: {
   task: Task;
   isActive: boolean;
+  status: Status;
 }) {
   const { attributes, listeners, setNodeRef, transform, isDragging } =
     useDraggable({ id: task.id });
@@ -131,7 +135,13 @@ function DraggableCard({
       <p className="text-[10px] font-medium text-[#71717a] uppercase tracking-wide mb-1 truncate">
         {task.phaseTitle}
       </p>
-      <p className="text-sm font-medium text-[#1a1a1a] leading-snug">{task.title}</p>
+      <p
+        className={`text-sm font-medium leading-snug ${
+          status === "cancelled" ? "text-[#a1a1aa] line-through" : "text-[#1a1a1a]"
+        }`}
+      >
+        {task.title}
+      </p>
       {task.description && (
         <p className="text-xs text-[#71717a] mt-1 leading-snug line-clamp-2">
           {task.description}
@@ -211,7 +221,7 @@ export function KanbanBoard({
       onDragStart={(e) => setActiveId(e.active.id as string)}
       onDragEnd={handleDragEnd}
     >
-      <div className="grid grid-cols-2 gap-4 xl:grid-cols-4">
+      <div className="grid grid-cols-2 gap-4 xl:grid-cols-5">
         {COLUMNS.map((col) => (
           <DroppableColumn
             key={col.id}

src/components/admin/tabs/PaymentsTab.tsx

@@ -9,6 +9,7 @@ import {
   setPaymentPaidAt,
   updatePaymentField,
   clearPaymentOverride,
+  setPaymentDueDate,
 } from "@/app/admin/clients/[id]/actions";
 import { setPaymentPlan } from "@/app/admin/projects/project-actions";
 import { Button } from "@/components/ui/button";
@@ -36,14 +37,19 @@ function formatEuro(value: number): string {
   return value.toLocaleString("it-IT", { minimumFractionDigits: 2 });
 }
 
-// paid_at (Date | string | null, serializzato sul confine RSC) → "YYYY-MM" per <input type="month">
-function toMonthValue(paidAt: Date | string | null | undefined): string {
-  if (!paidAt) {
+// Date | string | null (serializzato sul confine RSC) → "YYYY-MM-DD" per <input type="date">.
+// Le date sono salvate a mezzogiorno UTC apposta, quindi i getter locali leggono
+// il giorno giusto in qualunque fuso senza scivolare di uno.
+function toDateValue(value: Date | string | null | undefined): string {
+  if (!value) return "";
+  const d = value instanceof Date ? value : new Date(value);
+  if (Number.isNaN(d.getTime())) return "";
+  return `${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, "0")}-${String(d.getDate()).padStart(2, "0")}`;
+}
+
+function todayValue(): string {
   const now = new Date();
-    return `${now.getFullYear()}-${String(now.getMonth() + 1).padStart(2, "0")}`;
-  }
-  const d = paidAt instanceof Date ? paidAt : new Date(paidAt);
-  return `${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, "0")}`;
+  return `${now.getFullYear()}-${String(now.getMonth() + 1).padStart(2, "0")}-${String(now.getDate()).padStart(2, "0")}`;
 }
 
 type PlanMode = "single" | "two" | "three";
@@ -118,16 +124,19 @@ export function PaymentsTab({
   async function handleSetPlan(mode: PlanMode) {
     if (!projectId) return;
 
-    // Picking a plan deletes every existing row — including status and paid_at.
-    // Only worth interrupting when there is actually payment history to lose.
+    // Picking a plan deletes every existing row — including status, paid_at and
+    // due_date. Only worth interrupting when there is actually something to lose.
+    // La scadenza conta quanto lo stato: una rata "da saldare" con una data
+    // concordata è informazione che il cliente sta già leggendo nel portale, e
+    // sparirebbe senza che nessuno se ne accorga.
     const tracked = payments.filter(
-      (p) => p.status === "saldato" || p.status === "inviata"
+      (p) => p.status === "saldato" || p.status === "inviata" || p.due_date !== null
     ).length;
     if (tracked > 0) {
       const what =
-        tracked === 1 ? "1 rata già segnata" : `${tracked} rate già segnate`;
+        tracked === 1 ? "1 rata con dati inseriti" : `${tracked} rate con dati inseriti`;
       const ok = window.confirm(
-        `Cambiare schema cancella tutte le rate di questo progetto.\n\nCi sono ${what} come inviate o saldate: lo stato e il mese di incasso andranno persi.\n\nProcedere?`
+        `Cambiare schema cancella tutte le rate di questo progetto.\n\nCi sono ${what} (stato, scadenza o data di incasso): andranno persi.\n\nProcedere?`
       );
       if (!ok) return;
     }
@@ -155,11 +164,22 @@ export function PaymentsTab({
     }
   }
 
-  async function handlePaidMonthUpdate(paymentId: string, monthStr: string) {
-    if (!monthStr) return;
+  async function handlePaidDateUpdate(paymentId: string, dateStr: string) {
+    if (!dateStr) return;
     setStatusLoading(paymentId);
     try {
-      await setPaymentPaidAt(paymentId, clientId, monthStr);
+      await setPaymentPaidAt(paymentId, clientId, dateStr);
+      router.refresh();
+    } finally {
+      setStatusLoading(null);
+    }
+  }
+
+  // La scadenza si può anche togliere: la stringa vuota è un valore, non un no-op.
+  async function handleDueDateUpdate(paymentId: string, dateStr: string) {
+    setStatusLoading(paymentId);
+    try {
+      await setPaymentDueDate(paymentId, clientId, dateStr);
       router.refresh();
     } finally {
       setStatusLoading(null);
@@ -339,17 +359,36 @@ export function PaymentsTab({
               </select>
               {statusLoading === p.id && <span className="text-xs text-[#71717a]">...</span>}
             </div>
+            {/* Scadenza: è questa che il cliente vede nel portale, col conto alla
+                rovescia, ed è l'aggancio del futuro promemoria via email.
+                Sempre modificabile, anche a rata saldata: resta lo storico. */}
+            <div className="flex items-center gap-2 mt-2">
+              <Label htmlFor={`due-${p.id}`} className="text-xs text-[#71717a] shrink-0">
+                Scadenza
+              </Label>
+              <input
+                id={`due-${p.id}`}
+                type="date"
+                defaultValue={toDateValue(p.due_date)}
+                disabled={statusLoading === p.id}
+                onChange={(e) => handleDueDateUpdate(p.id, e.target.value)}
+                className="text-sm border border-gray-200 rounded px-2 py-1 bg-white"
+              />
+              {!p.due_date && (
+                <span className="text-xs text-[#a1a1aa]">non mostrata al cliente</span>
+              )}
+            </div>
             {p.status === "saldato" && (
               <div className="flex items-center gap-2 mt-2">
                 <Label htmlFor={`paid-${p.id}`} className="text-xs text-[#71717a] shrink-0">
-                  Incassato nel mese
+                  Incassato il
                 </Label>
                 <input
                   id={`paid-${p.id}`}
-                  type="month"
-                  defaultValue={toMonthValue(p.paid_at)}
+                  type="date"
+                  defaultValue={toDateValue(p.paid_at) || todayValue()}
                   disabled={statusLoading === p.id}
-                  onChange={(e) => handlePaidMonthUpdate(p.id, e.target.value)}
+                  onChange={(e) => handlePaidDateUpdate(p.id, e.target.value)}
                   className="text-sm border border-gray-200 rounded px-2 py-1 bg-white"
                 />
               </div>

src/components/client-dashboard.tsx

@@ -1,4 +1,5 @@
 import type { ClientView } from '@/lib/client-view';
+import { mentionCandidates } from '@/lib/mentions';
 import type { ChatData } from '@/lib/chat-channels';
 import { RefreshCw } from 'lucide-react';
 import { PhaseTimeline } from './phase-timeline';
@@ -23,9 +24,18 @@ interface ClientDashboardProps {
   embedded?: boolean;
   /** Anteprima admin: sola lettura, approvazioni e chat disattivate. */
   preview?: boolean;
+  /** Canale da aprire all'arrivo (`?chat=`), gia' validato dalla pagina. */
+  initialChatChannel?: string | null;
 }
 
-export function ClientDashboard({ view, token, chat, embedded = false, preview = false }: ClientDashboardProps) {
+export function ClientDashboard({
+  view,
+  token,
+  chat,
+  embedded = false,
+  preview = false,
+  initialChatChannel = null,
+}: ClientDashboardProps) {
   // Determine payment display mode based on active offers.
   // Solo i retainer ATTIVI cambiano la modalità: uno sospeso continuerebbe
   // altrimenti a intestare i pagamenti "Totale Pagamento Mensile" e a
@@ -43,7 +53,11 @@ export function ClientDashboard({ view, token, chat, embedded = false, preview =
 
   return (
     <PreviewProvider preview={preview}>
-    <ChatProvider phases={view.phases} clientId={view.client.id}>
+    <ChatProvider
+      phases={view.phases}
+      clientId={view.client.id}
+      initialChannel={initialChatChannel}
+    >
       <div className={embedded ? "" : "min-h-screen bg-background"}>
         {/* Header portale — iamcavalli · Client Portal | brand | area protetta */}
         {!embedded && (
@@ -161,7 +175,11 @@ export function ClientDashboard({ view, token, chat, embedded = false, preview =
         </footer>
 
         {/* Floating chat panel — FAB + slide-in panel */}
-        <ChatPanel token={token} chat={chat} />
+        <ChatPanel
+          token={token}
+          chat={chat}
+          mentionCandidates={mentionCandidates(view.client)}
+        />
       </div>
     </ChatProvider>
     </PreviewProvider>

src/components/client/ChatPanel.tsx

@@ -10,12 +10,13 @@ import {
   type ChatData,
   type ChatMessage,
 } from "@/lib/chat-channels";
+import { MentionText } from "@/components/ui/MentionText";
 import { useChatContext } from "./ChatProvider";
 import { usePreview } from "./PreviewProvider";
 
-// TODO: la mail di notifica al cliente ("hai un messaggio non letto") è un giro a
-// sé: serve uno scheduler, che nel repo non esiste ancora. Hook point naturale:
-// una query su client_channel_reads incrociata con comments.author = 'admin'.
+// La notifica via mail al cliente esiste, ma solo per i messaggi in cui l'admin
+// lo tagga (@Nome): parte da replyToConversation, senza scheduler. Una notifica
+// per OGNI messaggio non letto sarebbe un'altra cosa e richiederebbe un job.
 
 const POLL_MS = 20_000;
 /** Oltre questo scarto due messaggi dello stesso autore non si raggruppano più. */
@@ -60,7 +61,16 @@ function monogram(label: string): string {
   return (parts[0][0] + parts[1][0]).toUpperCase();
 }
 
-export function ChatPanel({ token, chat }: { token: string; chat: ChatData }) {
+export function ChatPanel({
+  token,
+  chat,
+  mentionCandidates,
+}: {
+  token: string;
+  chat: ChatData;
+  /** I nomi con cui l'admin può taggare questo cliente — vedi lib/mentions.ts. */
+  mentionCandidates: string[];
+}) {
   const {
     isOpen,
     expanded,
@@ -495,6 +505,7 @@ export function ChatPanel({ token, chat }: { token: string; chat: ChatData }) {
                 clientId={clientId}
                 adminName={adminName}
                 adminAvatarUrl={adminAvatarUrl}
+                mentionCandidates={mentionCandidates}
                 canEdit={!preview}
                 onEdit={applyEdit}
               />
@@ -605,6 +616,7 @@ function MessageList({
   clientId,
   adminName,
   adminAvatarUrl,
+  mentionCandidates,
   canEdit,
   onEdit,
 }: {
@@ -614,6 +626,7 @@ function MessageList({
   clientId: string;
   adminName: string;
   adminAvatarUrl: string | null;
+  mentionCandidates: string[];
   /** Falso in anteprima admin: si guarda, non si scrive. */
   canEdit: boolean;
   onEdit: (id: string, body: string) => Promise<boolean>;
@@ -647,6 +660,7 @@ function MessageList({
           grouped={grouped}
           adminName={adminName}
           adminAvatarUrl={adminAvatarUrl}
+          mentionCandidates={mentionCandidates}
           // Dentro un canale-fase, i messaggi storici su un task o un deliverable
           // restano riconoscibili: il canale li raccoglie, il badge dice su cosa erano.
           entityLabel={
@@ -676,6 +690,7 @@ function MessageRow({
   entityLabel,
   adminName,
   adminAvatarUrl,
+  mentionCandidates,
   canEdit,
   onEdit,
 }: {
@@ -686,6 +701,7 @@ function MessageRow({
   entityLabel?: string;
   adminName: string;
   adminAvatarUrl: string | null;
+  mentionCandidates: string[];
   canEdit: boolean;
   onEdit: (id: string, body: string) => Promise<boolean>;
 }) {
@@ -803,7 +819,7 @@ function MessageRow({
           ) : (
             <>
               <p className="mt-1 whitespace-pre-wrap text-sm leading-relaxed text-foreground">
-                {m.body}
+                <MentionText body={m.body} candidates={mentionCandidates} />
                 {m.edited_at && (
                   <span className="ml-1.5 text-[10px] text-muted-foreground">
                     (modificato)

src/components/client/ChatProvider.tsx

@@ -36,16 +36,31 @@ export function ChatProvider({
   children,
   phases,
   clientId,
+  initialChannel,
 }: {
   children: React.ReactNode;
   phases: ClientView["phases"];
   clientId: string;
+  /**
+   * Canale richiesto da fuori con `?chat=<key>` — è così che il pulsante della
+   * mail di tag porta il cliente dentro la conversazione giusta invece che sulla
+   * dashboard, dove la chat resterebbe chiusa e il messaggio non letto.
+   *
+   * Arriva dal server, già validato: leggerlo qui da `window.location` vorrebbe
+   * dire aprire il pannello in un effetto, cioè renderizzarlo chiuso e riaprirlo
+   * subito dopo l'idratazione.
+   */
+  initialChannel?: string | null;
 }) {
-  const [isOpen, setIsOpen] = useState(false);
+  // Un canale richiesto vale anche come "apri il pannello": chi arriva da quel
+  // link sta venendo a leggere un messaggio, non a guardare la timeline.
+  const [isOpen, setIsOpen] = useState(!!initialChannel);
   const [expanded, setExpanded] = useState(false);
   // Il canale "Generale" è identificato dall'id del cliente: stessa convenzione
   // di comments.entity_id, così non serve tradurre nulla in scrittura.
-  const [activeChannel, setActiveChannel] = useState<string>(clientId);
+  const [activeChannel, setActiveChannel] = useState<string>(
+    initialChannel ?? clientId
+  );
 
   const openChat = useCallback(
     (phaseId?: string) => {

src/components/client/PhaseCard.tsx

@@ -3,7 +3,12 @@
 import { useState } from "react";
 import { ApproveButton } from "@/components/client/ApproveButton";
 import { useChatContext } from "@/components/client/ChatProvider";
-import { TaskStatusIcon, TaskStatusPill } from "@/components/client/TaskStatusIndicator";
+import {
+  isClosedTaskStatus,
+  TaskStatusIcon,
+  TaskStatusPill,
+} from "@/components/client/TaskStatusIndicator";
+import { countsTowardProgress } from "@/lib/task-status";
 import type { ClientView } from "@/lib/client-view";
 
 type Phase = ClientView["phases"][number];
@@ -41,6 +46,10 @@ export function PhaseCard({
   const [open, setOpen] = useState(defaultOpen);
   const { openChat } = useChatContext();
   const doneCount = phase.tasks.filter((t) => t.status === "done").length;
+  // Il denominatore esclude le cancellate: "3 di 4" con una quarta voce annullata
+  // resterebbe fermo lì per sempre, e la barra non toccherebbe mai il 100%.
+  const countedTotal = phase.tasks.filter((t) => countsTowardProgress(t.status)).length;
+  const cancelledCount = phase.tasks.length - countedTotal;
   // I task in revisione aspettano il cliente, non noi. Il conteggio sta nell'header,
   // che resta visibile anche a card chiusa: altrimenti la richiesta si nasconde
   // dentro una fase collassata e il cliente non sa che tocca a lui.
@@ -94,13 +103,19 @@ export function PhaseCard({
         <div className="mb-1">
           <div className="flex justify-between items-center gap-3 mb-1.5">
             <p className="text-xs text-muted-foreground font-medium min-w-0">
-              {doneCount} di {phase.tasks.length} task
+              {doneCount} di {countedTotal} task
               {reviewCount > 0 && (
                 <span className="text-violet-600 dark:text-violet-400">
                   {" · "}
                   {reviewCount} in attesa di riscontro
                 </span>
               )}
+              {cancelledCount > 0 && (
+                <span>
+                  {" · "}
+                  {cancelledCount} {cancelledCount === 1 ? "cancellata" : "cancellate"}
+                </span>
+              )}
             </p>
             <p className="text-xs font-semibold text-foreground shrink-0">{phase.progress_pct}%</p>
           </div>
@@ -121,7 +136,10 @@ export function PhaseCard({
           ) : (
             <ul className="space-y-3">
               {phase.tasks.map((task) => (
-                <li key={task.id} className="flex items-start gap-3">
+                <li
+                  key={task.id}
+                  className={`flex items-start gap-3 ${task.status === "cancelled" ? "opacity-70" : ""}`}
+                >
                   <TaskStatusIcon status={task.status} />
                   <div className="flex-1 min-w-0">
                     {/* flex-wrap: su un titolo lungo la pill va a capo invece di
@@ -129,7 +147,7 @@ export function PhaseCard({
                     <div className="flex flex-wrap items-center gap-x-2 gap-y-1">
                       <p
                         className={`text-xs leading-snug ${
-                          task.status === "done"
+                          isClosedTaskStatus(task.status)
                             ? "line-through text-muted-foreground"
                             : "text-foreground"
                         }`}

src/components/client/TaskStatusIndicator.tsx

@@ -8,7 +8,8 @@
 // sono lo stesso oggetto, e il design system chiede il contrario — colore + testo,
 // mai colore da solo. Ora le quattro forme si distinguono anche in bianco e nero:
 // vuoto → punto → spunta vuota → spunta piena. La spunta compare quando il lavoro
-// è finito e si riempie quando è confermato.
+// è finito e si riempie quando è confermato. La cancellata è l'unica che non è
+// un passo avanti: X e testo barrato, tinta spenta, fuori da ogni conteggio.
 
 import { TASK_STATUSES, TASK_STATUS_LABELS, type TaskStatus } from "@/lib/task-status";
 
@@ -65,8 +66,24 @@ export const TASK_STATUS_VISUALS: Record<TaskStatus, StatusVisual> = {
     count: "bg-emerald-50 text-emerald-700 dark:bg-emerald-500/10 dark:text-emerald-400",
     hint: "Fatto — completato.",
   },
+  cancelled: {
+    ring: "border-2 border-border bg-muted text-muted-foreground",
+    // Unica pill fra gli stati chiusi: "fatto" e "cancellata" sono entrambi
+    // barrati, e la differenza fra i due — consegnato o tolto dal lavoro — è
+    // troppo importante per affidarla al solo disegno dentro il cerchio.
+    pill: "bg-muted text-muted-foreground border border-border",
+    dot: "bg-muted-foreground/40",
+    label: "text-muted-foreground",
+    count: "bg-muted text-muted-foreground",
+    hint: "Cancellata — non verrà realizzata.",
+  },
 };
 
+/** Stati chiusi: il titolo si legge barrato, il lavoro non è più in corso. */
+export function isClosedTaskStatus(status: TaskStatus): boolean {
+  return status === "done" || status === "cancelled";
+}
+
 function CheckGlyph({ className }: { className: string }) {
   return (
     <svg
@@ -82,12 +99,27 @@ function CheckGlyph({ className }: { className: string }) {
   );
 }
 
+function CrossGlyph({ className }: { className: string }) {
+  return (
+    <svg
+      className={className}
+      fill="none"
+      stroke="currentColor"
+      strokeWidth={3}
+      viewBox="0 0 24 24"
+      aria-hidden="true"
+    >
+      <path strokeLinecap="round" strokeLinejoin="round" d="M6 6l12 12M18 6L6 18" />
+    </svg>
+  );
+}
+
 /**
  * Il cerchio di stato accanto al titolo del task.
  *
  * L'icona è decorativa (`aria-hidden`) e lo stato viaggia in uno `sr-only`: così
- * lo screen reader lo annuncia su tutti e quattro gli stati, mentre a schermo solo
- * i due ambigui portano la pill.
+ * lo screen reader lo annuncia su tutti gli stati, mentre a schermo solo quelli
+ * ambigui portano la pill.
  */
 export function TaskStatusIcon({ status }: { status: TaskStatus }) {
   const v = TASK_STATUS_VISUALS[status];
@@ -99,6 +131,7 @@ export function TaskStatusIcon({ status }: { status: TaskStatus }) {
         className={`mt-0.5 flex h-5 w-5 shrink-0 items-center justify-center rounded-full ${v.ring}`}
       >
         {status === "done" && <CheckGlyph className="h-3 w-3" />}
+        {status === "cancelled" && <CrossGlyph className="h-2.5 w-2.5" />}
         {status === "in_review" && (
           <CheckGlyph className="h-2.5 w-2.5 text-violet-600 dark:text-violet-400" />
         )}
@@ -115,8 +148,8 @@ export function TaskStatusIcon({ status }: { status: TaskStatus }) {
  * Etichetta di testo. Nulla per "da fare" e "fatto", che si leggono da soli.
  *
  * `aria-hidden` perché è ridondanza *visiva*: allo screen reader lo stato lo dice già
- * lo `sr-only` dell'icona, su tutti e quattro gli stati. Senza questo, i due che hanno
- * la pill verrebbero annunciati due volte.
+ * lo `sr-only` dell'icona, su tutti gli stati. Senza questo, quelli che hanno la pill
+ * verrebbero annunciati due volte.
  */
 export function TaskStatusPill({ status }: { status: TaskStatus }) {
   const v = TASK_STATUS_VISUALS[status];
@@ -139,11 +172,16 @@ export function TaskStatusPill({ status }: { status: TaskStatus }) {
  * disciplina introdotta insieme allo stato "in revisione", dopo che due liste
  * fisse avevano già fatto sparire task dal portale senza un errore.
  */
-export function TaskStatusLegend() {
+export function TaskStatusLegend({ showCancelled = false }: { showCancelled?: boolean }) {
+  // "Cancellata" è l'unica voce condizionata: nella maggior parte dei progetti non
+  // ce n'è nessuna, e spiegare a tutti uno stato che non vedranno mai è rumore.
+  // La condizione guarda i task veri: se una cancellata c'è, la legenda la spiega.
+  const statuses = TASK_STATUSES.filter((s) => s !== "cancelled" || showCancelled);
+
   return (
     <div className="mb-6 rounded-lg bg-muted/50 px-4 py-3">
       <ul className="flex flex-wrap items-center gap-x-5 gap-y-2">
-        {TASK_STATUSES.map((status) => (
+        {statuses.map((status) => (
           <li key={status} className="flex items-center gap-1.5">
             <span
               aria-hidden="true"
@@ -160,6 +198,13 @@ export function TaskStatusLegend() {
         aspetta il tuo riscontro: scrivicelo dalla chat della fase. Ogni pagina include un giro di
         revisione.
       </p>
+      {showCancelled && (
+        <p className="mt-1 text-[11px] leading-snug text-muted-foreground">
+          <span className="font-semibold text-foreground">Cancellata</span> — l&apos;attività è
+          stata tolta dal lavoro, d&apos;accordo con te: resta scritta ma non verrà realizzata, e
+          non pesa sull&apos;avanzamento.
+        </p>
+      )}
     </div>
   );
 }

src/components/client/kanban/ClientKanban.tsx

@@ -2,7 +2,7 @@
 
 import type { ClientView } from "@/lib/client-view";
 import { ApproveButton } from "@/components/client/ApproveButton";
-import { TASK_STATUS_VISUALS } from "@/components/client/TaskStatusIndicator";
+import { isClosedTaskStatus, TASK_STATUS_VISUALS } from "@/components/client/TaskStatusIndicator";
 import { TASK_STATUS_LABELS, TASK_STATUSES, type TaskStatus } from "@/lib/task-status";
 
 type Task = ClientView["phases"][number]["tasks"][number] & {
@@ -16,11 +16,15 @@ const COLUMNS: { id: TaskStatus; label: string }[] = TASK_STATUSES.map((id) => (
 
 function TaskCard({ task, token }: { task: Task; token: string }) {
   return (
-    <div className="bg-card rounded-lg border border-border-light px-4 py-4 shadow-sm hover:border-primary/30 hover:shadow-card-hover transition-all">
+    <div
+      className={`bg-card rounded-lg border border-border-light px-4 py-4 shadow-sm hover:border-primary/30 hover:shadow-card-hover transition-all ${
+        task.status === "cancelled" ? "opacity-70" : ""
+      }`}
+    >
       <p className="text-[9px] font-semibold text-muted-foreground uppercase tracking-wide mb-1 truncate">
         {task.phaseTitle}
       </p>
-      <p className={`text-xs font-medium leading-snug ${task.status === "done" ? "line-through text-muted-foreground" : "text-foreground"}`}>
+      <p className={`text-xs font-medium leading-snug ${isClosedTaskStatus(task.status) ? "line-through text-muted-foreground" : "text-foreground"}`}>
         {task.title}
       </p>
       {task.description && (
@@ -58,9 +62,21 @@ export function ClientKanban({ phases, token }: { phases: ClientView["phases"];
     {} as Record<TaskStatus, Task[]>
   );
 
+  // "Cancellate" è l'unica colonna che si nasconde da vuota: nella maggior parte
+  // dei progetti non ce n'è nessuna, e una quinta colonna vuota ruberebbe spazio
+  // alle quattro che raccontano il lavoro. Si nasconde solo se è vuota, quindi
+  // nessun task sparisce mai dalla board — era proprio quello il bug di prima.
+  const visibleColumns = COLUMNS.filter(
+    (col) => col.id !== "cancelled" || tasksByStatus.cancelled.length > 0
+  );
+
   return (
-    <div className="grid grid-cols-1 gap-6 sm:grid-cols-2 xl:grid-cols-4">
-      {COLUMNS.map((col) => {
+    <div
+      className={`grid grid-cols-1 gap-6 sm:grid-cols-2 ${
+        visibleColumns.length > 4 ? "xl:grid-cols-5" : "xl:grid-cols-4"
+      }`}
+    >
+      {visibleColumns.map((col) => {
         // Stessa tinta dell'icona in Timeline: passando da una vista all'altra
         // "in corso" e "in revisione" restano riconoscibili senza rileggere.
         const v = TASK_STATUS_VISUALS[col.id];

src/components/client/kanban/PhaseViewToggle.tsx

@@ -15,6 +15,7 @@ export function PhaseViewToggle({
   token: string;
 }) {
   const [view, setView] = useState<"timeline" | "kanban">("timeline");
+  const hasCancelled = phases.some((p) => p.tasks.some((t) => t.status === "cancelled"));
 
   return (
     <div>
@@ -41,7 +42,7 @@ export function PhaseViewToggle({
       </div>
 
       {/* Fuori dallo switch: gli stati sono gli stessi in entrambe le viste */}
-      <TaskStatusLegend />
+      <TaskStatusLegend showCancelled={hasCancelled} />
 
       {view === "timeline" ? timelineView : <ClientKanban phases={phases} token={token} />}
     </div>

src/components/payment-status.tsx

@@ -1,4 +1,11 @@
 import type { ClientView } from '@/lib/client-view';
+import {
+  daysUntil,
+  findNextDue,
+  formatCountdown,
+  formatLongDate,
+  formatShortDate,
+} from '@/lib/payment-dates';
 
 interface PaymentStatusProps {
   accepted_total: string;
@@ -49,6 +56,16 @@ export function PaymentStatus({
     maximumFractionDigits: 2,
   });
 
+  // Il conto alla rovescia si calcola qui, sul server: la pagina è dinamica
+  // (`revalidate = 0`), quindi il numero è fresco a ogni apertura del portale.
+  //
+  // Il riquadro compare anche quando le righe sono nascoste (retainer): non
+  // contiene importi, e una scadenza esiste solo se l'admin l'ha scritta — se
+  // l'ha scritta, è perché il cliente la deve sapere.
+  const nextDue = findNextDue(payments);
+  const nextDueDays = nextDue?.due_date ? daysUntil(nextDue.due_date) : null;
+  const isLate = nextDueDays !== null && nextDueDays < 0;
+
   return (
     <div className="rounded-xl border border-border-light bg-card shadow-card overflow-hidden">
       {/* Totale — unico importo visibile al cliente (LOCKED) */}
@@ -61,7 +78,34 @@ export function PaymentStatus({
         </p>
       </div>
 
-      {/* Righe pagamento: solo etichetta + stato, MAI importo singolo — omesse se hideRows */}
+      {/* Prossima scadenza — la domanda più ovvia del cliente, in cima e senza cifre */}
+      {nextDue && nextDue.due_date && nextDueDays !== null && (
+        <div
+          className={`px-5 py-4 border-b border-border-light ${
+            isLate
+              ? 'bg-red-50 dark:bg-red-500/10'
+              : 'bg-amber-50/60 dark:bg-amber-500/10'
+          }`}
+        >
+          <p
+            className={`text-[10px] font-bold uppercase tracking-wider mb-1 ${
+              isLate
+                ? 'text-red-700 dark:text-red-400'
+                : 'text-amber-700 dark:text-amber-400'
+            }`}
+          >
+            {isLate ? 'Pagamento scaduto' : 'Prossimo pagamento'}
+          </p>
+          <p className="text-sm font-bold text-foreground leading-snug">
+            {formatLongDate(nextDue.due_date)}
+          </p>
+          <p className="text-xs text-muted-foreground mt-0.5">
+            {nextDue.label} · {formatCountdown(nextDueDays)}
+          </p>
+        </div>
+      )}
+
+      {/* Righe pagamento: solo etichetta, stato e date — MAI importo singolo */}
       {!hideRows && (
         <div className="px-5 py-4 space-y-2">
           {payments.length === 0 ? (
@@ -73,14 +117,42 @@ export function PaymentStatus({
               const status = payment.status as PaymentStatusValue;
               const config = statusConfig[status] ?? statusConfig.da_saldare;
 
+              // Una riga saldata mostra quando è stata incassata; una ancora
+              // aperta mostra quando scade. Nessuna delle due inventa la data:
+              // se in gestionale non c'è, sotto l'etichetta non compare nulla.
+              const paidOn =
+                status === 'saldato' && payment.paid_at
+                  ? `Pagato il ${formatShortDate(payment.paid_at)}`
+                  : null;
+              const dueOn =
+                status !== 'saldato' && payment.due_date
+                  ? `Scade il ${formatShortDate(payment.due_date)} · ${formatCountdown(
+                      daysUntil(payment.due_date)
+                    )}`
+                  : null;
+              const overdue = dueOn !== null && daysUntil(payment.due_date!) < 0;
+
               return (
                 <div
                   key={payment.id}
-                  className="flex items-center justify-between gap-4 rounded-lg border border-border-light p-3"
+                  className="flex items-start justify-between gap-4 rounded-lg border border-border-light p-3"
                 >
+                  <div className="min-w-0">
                     <p className="text-xs font-semibold text-foreground">
                       {payment.label}
                     </p>
+                    {(paidOn || dueOn) && (
+                      <p
+                        className={`text-[11px] mt-0.5 leading-snug ${
+                          overdue
+                            ? 'text-red-600 dark:text-red-400'
+                            : 'text-muted-foreground'
+                        }`}
+                      >
+                        {paidOn ?? dueOn}
+                      </p>
+                    )}
+                  </div>
 
                   {/* Pill stato — nessun importo */}
                   <span

src/components/ui/MentionText.tsx

@@ -0,0 +1,44 @@
+import { Fragment } from "react";
+import { cn } from "@/lib/utils";
+import { splitMentions } from "@/lib/mentions";
+
+/**
+ * Corpo di un messaggio di chat con le menzioni evidenziate.
+ *
+ * Sostituisce `{m.body}` dentro il paragrafo: mantiene `whitespace-pre-wrap` sul
+ * genitore, quindi gli a capo continuano a funzionare senza dover spezzare il
+ * testo in righe qui dentro.
+ */
+export function MentionText({
+  body,
+  candidates,
+  mentionClassName,
+}: {
+  body: string;
+  candidates: string[];
+  /** Il contrasto cambia col fondo della bolla: lo decide chi la disegna. */
+  mentionClassName?: string;
+}) {
+  const parts = splitMentions(body, candidates);
+
+  return (
+    <>
+      {parts.map((part, i) =>
+        part.type === "mention" ? (
+          <span
+            key={i}
+            className={cn(
+              "rounded px-1 font-semibold",
+              mentionClassName ??
+                "bg-primary/10 text-primary dark:bg-primary/20"
+            )}
+          >
+            {part.value}
+          </span>
+        ) : (
+          <Fragment key={i}>{part.value}</Fragment>
+        )
+      )}
+    </>
+  );
+}

src/db/migrations/0023_payments_due_date.sql

@@ -0,0 +1,19 @@
+-- Additive: la data in cui una rata è attesa.
+--
+-- Perché: `payments` sapeva solo QUANDO una rata è stata incassata (paid_at) e mai
+-- quando ci si aspetta che lo sia. Il portale non poteva quindi rispondere alla
+-- domanda più ovvia del cliente — "quando devo pagare?" — e non c'era nessun campo
+-- su cui agganciare il promemoria via email prima della scadenza.
+--
+-- Nullable senza default: una rata senza data concordata è normale, e un default
+-- (per esempio "oggi") inventerebbe una scadenza che nessuno ha pattuito. Il
+-- portale mostra la scadenza solo se c'è.
+--
+-- Nessun DROP, nessun TRUNCATE, nessuna DELETE — `payments` è LOCKED in CLAUDE.md.
+
+ALTER TABLE payments ADD COLUMN IF NOT EXISTS due_date timestamptz;
+
+-- Il promemoria email cercherà "le rate non saldate in scadenza entro N giorni":
+-- è una scansione su tutta la tabella filtrata per data, non per progetto, quindi
+-- l'indice esistente (project_id, sort_order) non la copre.
+CREATE INDEX IF NOT EXISTS payments_due_date_idx ON payments(due_date) WHERE due_date IS NOT NULL;

src/db/schema.ts

@@ -249,6 +249,9 @@ export const payments = pgTable("payments", {
   percent: numeric("percent", { precision: 5, scale: 2 }), // nullable — % of total (for rescaling); null = legacy row
   status: text("status").notNull().default("da_saldare"), // da_saldare | inviata | saldato
   paid_at: timestamp("paid_at", { withTimezone: true }),
+  // Scadenza concordata. Nullable: non tutte le rate ne hanno una, e il portale
+  // la mostra al cliente solo quando c'è. È anche l'aggancio del promemoria email.
+  due_date: timestamp("due_date", { withTimezone: true }),
   sort_order: integer("sort_order").notNull().default(0),
   // true = l'importo è stato scritto a mano: rescalePayments non lo tocca più.
   amount_locked: boolean("amount_locked").notNull().default(false),

src/lib/client-notifications.ts

@@ -0,0 +1,160 @@
+import { eq } from "drizzle-orm";
+import { db } from "@/db";
+import { clients, client_emails, phases } from "@/db/schema";
+import { mentionEmailTemplate, sendEmail } from "@/lib/mailer";
+import { getAdminIdentity } from "@/lib/settings";
+import { GENERAL_LABEL } from "@/lib/chat-channels";
+
+/**
+ * Notifica al cliente che è stato taggato in chat.
+ *
+ * Il portale non manda una notifica per ogni messaggio, e non deve: il cliente
+ * lo apre quando gli pare. Il tag è l'eccezione dichiarata — l'admin decide che
+ * quel messaggio non può aspettare il prossimo accesso, e quella decisione vale
+ * una mail. Nessuno scheduler, nessuna coda: l'invio parte dalla stessa azione
+ * che scrive il messaggio.
+ */
+
+/**
+ * Gli indirizzi che ricevono la notifica: la whitelist OTP (le persone che
+ * possono davvero entrare nel portale) più l'indirizzo di contatto sulla scheda.
+ * Deduplicati senza distinzione di maiuscole, perché lo stesso indirizzo scritto
+ * in due modi è una persona sola.
+ */
+export async function getMentionRecipients(clientId: string): Promise<string[]> {
+  const [whitelisted, clientRows] = await Promise.all([
+    db
+      .select({ email: client_emails.email })
+      .from(client_emails)
+      .where(eq(client_emails.client_id, clientId)),
+    db
+      .select({ email: clients.email })
+      .from(clients)
+      .where(eq(clients.id, clientId))
+      .limit(1),
+  ]);
+
+  const seen = new Set<string>();
+  const out: string[] = [];
+  for (const value of [
+    ...whitelisted.map((r) => r.email),
+    clientRows[0]?.email ?? null,
+  ]) {
+    const email = value?.trim();
+    if (!email) continue;
+    const key = email.toLowerCase();
+    if (seen.has(key)) continue;
+    seen.add(key);
+    out.push(email);
+  }
+  return out;
+}
+
+/**
+ * Base pubblica del portale. `NEXTAUTH_URL` è già l'origine giusta in ogni
+ * ambiente; `APP_BASE_URL` esiste solo per il caso in cui le due debbano
+ * divergere. Se manca tutto si torna null: meglio una mail senza link che una
+ * mail con un link a localhost.
+ */
+function portalBaseUrl(): string | null {
+  const raw = process.env.APP_BASE_URL ?? process.env.NEXTAUTH_URL;
+  const trimmed = raw?.trim().replace(/\/+$/, "");
+  return trimmed || null;
+}
+
+type MentionInput = {
+  clientId: string;
+  /** clients.id per "Generale", phases.id per una fase. */
+  channelKey: string;
+  body: string;
+};
+
+export type MentionNotifyResult = {
+  /** Quante mail sono partite davvero. */
+  sent: number;
+  recipients: number;
+  errors: string[];
+};
+
+/**
+ * Non lancia mai: il messaggio in chat è già stato scritto e resta valido anche
+ * se Resend è giù. Un errore d'invio si logga e si restituisce, non si propaga
+ * fino a far sembrare fallita la risposta al cliente.
+ */
+export async function notifyClientMention({
+  clientId,
+  channelKey,
+  body,
+}: MentionInput): Promise<MentionNotifyResult> {
+  const result: MentionNotifyResult = { sent: 0, recipients: 0, errors: [] };
+
+  try {
+    const [clientRow] = await db
+      .select({
+        name: clients.name,
+        brand_name: clients.brand_name,
+        token: clients.token,
+        slug: clients.slug,
+      })
+      .from(clients)
+      .where(eq(clients.id, clientId))
+      .limit(1);
+    if (!clientRow) return result;
+
+    const recipients = await getMentionRecipients(clientId);
+    result.recipients = recipients.length;
+    if (recipients.length === 0) return result;
+
+    const [admin, channelLabel] = await Promise.all([
+      getAdminIdentity(),
+      resolveChannelLabel(clientId, channelKey),
+    ]);
+
+    const base = portalBaseUrl();
+    // Lo slug è il link "bello" quando c'è; il token è sempre valido. Entrambi
+    // sono credenziali al portatore: finiscono solo nella mail del cliente.
+    const url = base
+      ? `${base}/client/${clientRow.slug ?? clientRow.token}?chat=${encodeURIComponent(channelKey)}`
+      : null;
+
+    const { subject, html } = mentionEmailTemplate({
+      clientName: clientRow.name,
+      adminName: admin.name,
+      channelLabel,
+      body,
+      url,
+    });
+
+    // In serie e non in parallelo: sono uno o due indirizzi, e un 429 di Resend
+    // su un burst costerebbe più di quanto valga la concorrenza.
+    for (const to of recipients) {
+      const outcome = await sendEmail({ to, subject, html });
+      if (outcome.ok) result.sent++;
+      else result.errors.push(`${to}: ${outcome.error}`);
+    }
+
+    if (result.errors.length > 0) {
+      console.error("[notifyClientMention] invii falliti:", result.errors.join(" | "));
+    }
+  } catch (err) {
+    const message = err instanceof Error ? err.message : "errore sconosciuto";
+    result.errors.push(message);
+    console.error("[notifyClientMention] errore:", message);
+  }
+
+  return result;
+}
+
+/** "Generale" o il titolo della fase: è la stessa etichetta che il cliente vede sul tab. */
+async function resolveChannelLabel(
+  clientId: string,
+  channelKey: string
+): Promise<string> {
+  if (channelKey === clientId) return GENERAL_LABEL;
+  const [row] = await db
+    .select({ title: phases.title })
+    .from(phases)
+    .where(eq(phases.id, channelKey))
+    .limit(1);
+  return row?.title?.trim() || GENERAL_LABEL;
+}

src/lib/client-view.ts

@@ -1,7 +1,7 @@
 import { eq, ne, and, inArray, asc, desc } from "drizzle-orm";
 import { db } from "@/db";
 import { clients, projects, phases, tasks, deliverables, payments, documents, notes, comments, client_channel_reads, project_offers, offer_micros, offer_macros, clientTranscripts } from "@/db/schema";
-import type { TaskStatus } from "@/lib/task-status";
+import { countsTowardProgress, type TaskStatus } from "@/lib/task-status";
 import { getComputedOfferValues } from "@/lib/offer-value";
 
 /**
@@ -42,6 +42,10 @@ export interface ClientView {
     id: string;
     label: string;
     status: "da_saldare" | "inviata" | "saldato";
+    // Le date sì, gli importi no: il cliente deve sapere quando paga e quando ha
+    // pagato — quanto, per singola rata, resta fuori dall'API cliente (LOCKED #2).
+    due_date: string | null;   // ISO
+    paid_at: string | null;    // ISO
   }>;
   documents: Array<{
     id: string;
@@ -108,6 +112,8 @@ export interface ProjectView {
     label: string;
     // amount intentionally excluded — client API never exposes payment amounts (CLAUDE.md + DASH-07)
     status: string;
+    due_date: Date | null;
+    paid_at: Date | null;
   }>;
   documents: Array<{
     id: string;
@@ -326,6 +332,10 @@ export async function getProjectView(projectId: string): Promise<ProjectView | n
       id: payments.id,
       label: payments.label,
       status: payments.status,
+      // Date sì, importo no: la scadenza e l'incasso servono al cliente per
+      // sapere quando paga; l'importo della singola rata resta escluso.
+      due_date: payments.due_date,
+      paid_at: payments.paid_at,
       // amount intentionally excluded — client API never exposes payment amounts
     })
     .from(payments)
@@ -446,16 +456,20 @@ export async function getProjectView(projectId: string): Promise<ProjectView | n
         deliverables: deliverablesRows.filter((d) => d.task_id === task.id),
       }));
 
-    const doneCount = phaseTasks.filter((t) => t.status === "done").length;
+    // I task cancellati escono dal denominatore: restano in lista, barrati, ma
+    // non tengono la fase sotto il 100% per un lavoro che nessuno farà più.
+    const countedTasks = phaseTasks.filter((t) => countsTowardProgress(t.status));
+    const doneCount = countedTasks.filter((t) => t.status === "done").length;
     const progress_pct =
-      phaseTasks.length > 0 ? Math.round((doneCount / phaseTasks.length) * 100) : 0;
+      countedTasks.length > 0 ? Math.round((doneCount / countedTasks.length) * 100) : 0;
 
     return { ...phase, tasks: phaseTasks, progress_pct };
   });
 
-  const doneTasks = tasksRows.filter((t) => t.status === "done").length;
+  const countedTasks = tasksRows.filter((t) => countsTowardProgress(t.status));
+  const doneTasks = countedTasks.filter((t) => t.status === "done").length;
   const global_progress_pct =
-    tasksRows.length > 0 ? Math.round((doneTasks / tasksRows.length) * 100) : 0;
+    countedTasks.length > 0 ? Math.round((doneTasks / countedTasks.length) * 100) : 0;
 
   return {
     project: {

src/lib/conversations-queries.ts

@@ -4,6 +4,8 @@ import { clients, projects, phases, tasks, deliverables, comments } from "@/db/s
 import { eq, inArray, asc } from "drizzle-orm";
 import type { Comment } from "@/db/schema";
 import { buildChannels, type ChatChannel } from "@/lib/chat-channels";
+import { mentionTargets, mentionAliases, type MentionTarget } from "@/lib/mentions";
+import { getMentionRecipients } from "@/lib/client-notifications";
 
 // ── Types ─────────────────────────────────────────────────────────────────────
 
@@ -13,9 +15,11 @@ export type ConversationSummary = {
   brand_name: string;
   token: string;
   slug: string | null;
+  /** Stringa vuota per un cliente con cui non si e' ancora scambiato nulla. */
   lastMessage: string;
-  lastMessageAuthor: "client" | "admin";
-  lastMessageAt: Date;
+  lastMessageAuthor: "client" | "admin" | null;
+  /** null = nessun messaggio: la conversazione esiste ma e' ancora da aprire. */
+  lastMessageAt: Date | null;
   lastEntityLabel: string;
   unread: boolean;
   unreadCount: number;
@@ -54,6 +58,23 @@ export type ConversationThread = {
    * refresh il dato non sarebbe più ricostruibile.
    */
   adminLastReadAt: Date | null;
+  /**
+   * **Chi** si può taggare: una voce per destinatario, per il menu del
+   * compositore. Oggi ne esce sempre una — la chat è 1:1.
+   */
+  mentionTargets: MentionTarget[];
+  /**
+   * **Come** un tag viene riconosciuto rileggendo il testo: tutti gli alias di
+   * tutti i destinatari. Serve solo a evidenziare, mai a offrire una scelta —
+   * confondere le due liste è ciò che faceva comparire tre voci per una persona.
+   */
+  mentionAliases: string[];
+  /**
+   * Quanti indirizzi riceverebbero la notifica di un tag. Zero significa che il
+   * tag resta un'evidenziazione e basta: il compositore lo dice prima, invece di
+   * lasciar credere che sia partita una mail che non partirà.
+   */
+  notifyEmailCount: number;
 };
 
 type ClientMeta = {
@@ -221,17 +242,26 @@ async function fetchComments(allEntityIds: string[]): Promise<Comment[]> {
 
 // ── Public API ──────────────────────────────────────────────────────────────────
 
-/** One entry per non-archived client that has at least one comment, newest first. */
+/**
+ * Una voce per OGNI cliente non archiviato, anche senza un solo messaggio.
+ *
+ * Prima l'elenco nasceva dai commenti, quindi un cliente compariva solo dopo
+ * aver scritto per primo: dall'inbox era letteralmente impossibile aprire una
+ * conversazione. Il centro messaggi è la rubrica dei clienti, non l'archivio di
+ * chi ha già parlato — la lista parte da `clients` e i commenti la arricchiscono.
+ *
+ * Ordine: prima chi ha scritto, dal più recente; in coda chi non ha ancora
+ * niente, in ordine alfabetico. Così l'inbox resta un inbox e i clienti muti
+ * non spingono giù le conversazioni vive.
+ */
 export async function getConversations(): Promise<ConversationSummary[]> {
   const { clientMeta, entityMap, allEntityIds } = await buildEntityMap();
   const commentRows = await fetchComments(allEntityIds);
   const byClient = groupCommentsByClient(commentRows, entityMap);
 
   const summaries: ConversationSummary[] = [];
-  for (const [clientId, msgs] of byClient) {
-    const meta = clientMeta.get(clientId);
-    if (!meta || msgs.length === 0) continue;
-
+  for (const meta of clientMeta.values()) {
+    const msgs = byClient.get(meta.id) ?? [];
     const last = msgs[msgs.length - 1];
     const lastReadAt = meta.admin_last_read_at?.getTime() ?? 0;
     const clientMsgsAfterRead = msgs.filter(
@@ -239,21 +269,28 @@ export async function getConversations(): Promise<ConversationSummary[]> {
     );
 
     summaries.push({
-      clientId,
+      clientId: meta.id,
       name: meta.name,
       brand_name: meta.brand_name,
       token: meta.token,
       slug: meta.slug,
-      lastMessage: last.body,
-      lastMessageAuthor: last.author as "client" | "admin",
-      lastMessageAt: last.created_at,
-      lastEntityLabel: entityMap.get(last.entity_id)?.label ?? "Generale",
+      lastMessage: last?.body ?? "",
+      lastMessageAuthor: (last?.author as "client" | "admin") ?? null,
+      lastMessageAt: last?.created_at ?? null,
+      lastEntityLabel: last ? entityMap.get(last.entity_id)?.label ?? "Generale" : "Generale",
       unread: clientMsgsAfterRead.length > 0,
       unreadCount: clientMsgsAfterRead.length,
     });
   }
 
-  summaries.sort((a, b) => b.lastMessageAt.getTime() - a.lastMessageAt.getTime());
+  summaries.sort((a, b) => {
+    if (a.lastMessageAt && b.lastMessageAt) {
+      return b.lastMessageAt.getTime() - a.lastMessageAt.getTime();
+    }
+    if (a.lastMessageAt) return -1;
+    if (b.lastMessageAt) return 1;
+    return a.name.localeCompare(b.name, "it");
+  });
   return summaries;
 }
 
@@ -271,6 +308,10 @@ export async function getConversationThread(
   );
   const commentRows = await fetchComments(ownEntityIds);
 
+  // Calcolati una volta: gli alias derivano dai target, e ricavarli due volte
+  // aprirebbe la porta a un menu e a un'evidenziazione che non concordano.
+  const targets = mentionTargets(meta);
+
   const messages: ThreadMessage[] = commentRows.map((c) => {
     const info = entityMap.get(c.entity_id);
     return {
@@ -296,6 +337,9 @@ export async function getConversationThread(
     messages,
     channels: buildChannels(meta.id, phasesByClient.get(clientId) ?? []),
     adminLastReadAt: meta.admin_last_read_at,
+    mentionTargets: targets,
+    mentionAliases: mentionAliases(targets),
+    notifyEmailCount: (await getMentionRecipients(clientId)).length,
   };
 }
 

src/lib/delivery-queries.ts

@@ -9,6 +9,7 @@ import {
   offer_macros,
 } from "@/db/schema";
 import { eq, inArray } from "drizzle-orm";
+import { countsTowardProgress } from "@/lib/task-status";
 
 export type DeliveryStatus = "consegnato" | "in_anticipo" | "in_linea" | "in_ritardo";
 
@@ -131,6 +132,9 @@ export async function getDeliveryBoard(): Promise<DeliveryBoard> {
   for (const task of taskRows) {
     const projectId = phaseToProject.get(task.phase_id);
     if (!projectId) continue;
+    // Le cancellate non entrano nel totale: il board di consegna misura quanto
+    // manca, e quello che è stato tolto dal lavoro non manca più.
+    if (!countsTowardProgress(task.status)) continue;
     const tally = taskTally.get(projectId) ?? { done: 0, total: 0 };
     tally.total += 1;
     if (task.status === "done") tally.done += 1;

src/lib/mailer.ts

@@ -73,6 +73,67 @@ export function otpEmailTemplate(code: string, brandName: string): { subject: st
   };
 }
 
+/**
+ * Notifica «ti hanno taggato in chat».
+ *
+ * Il cliente apre il portale quando gli pare: senza questa mail un messaggio
+ * urgente resta lì finché non gli viene in mente di guardare. Il testo dice una
+ * cosa sola — c'è un messaggio per te, qui — e ci porta con un pulsante.
+ *
+ * L'estratto è volutamente corto: serve a far capire di cosa si parla, non a
+ * sostituire la chat. La conversazione si legge nel portale, dove si risponde.
+ */
+export function mentionEmailTemplate({
+  clientName,
+  adminName,
+  channelLabel,
+  body,
+  url,
+}: {
+  clientName: string;
+  adminName: string;
+  channelLabel: string;
+  body: string;
+  /** null se la base pubblica non è configurata: la mail parte comunque, senza pulsante. */
+  url: string | null;
+}): { subject: string; html: string } {
+  const firstName = clientName.trim().split(/\s+/)[0] || clientName;
+  const excerpt = truncate(body, 280);
+
+  const button = url
+    ? `<p style="margin:0 0 24px;"><a href="${escapeHtml(url)}" style="display:inline-block;background:#1a1a1a;color:#ffffff;text-decoration:none;font-size:15px;font-weight:600;padding:14px 28px;border-radius:8px;">Apri la conversazione</a></p>`
+    : "";
+
+  return {
+    subject: `${adminName} ti ha taggato in chat`,
+    html: `<!doctype html>
+<html lang="it">
+  <body style="margin:0;padding:32px 16px;background:#f6f6f4;font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif;color:#1a1a1a;">
+    <table role="presentation" cellpadding="0" cellspacing="0" style="max-width:480px;margin:0 auto;background:#ffffff;border-radius:12px;padding:32px;">
+      <tr><td>
+        <p style="margin:0 0 8px;font-size:14px;color:#71717a;">${escapeHtml(channelLabel)}</p>
+        <h1 style="margin:0 0 24px;font-size:20px;font-weight:600;">${escapeHtml(firstName)}, ${escapeHtml(adminName)} ti ha taggato in chat</h1>
+        <table role="presentation" cellpadding="0" cellspacing="0" style="width:100%;margin:0 0 24px;background:#f6f6f4;border-radius:8px;">
+          <tr><td style="padding:16px 18px;font-size:15px;line-height:1.6;color:#1a1a1a;">${escapeHtml(excerpt).replace(/\n/g, "<br>")}</td></tr>
+        </table>
+        ${button}
+        <p style="margin:0;font-size:14px;color:#71717a;line-height:1.6;">Rispondi dal portale: la conversazione resta lì, insieme al progetto.</p>
+      </td></tr>
+    </table>
+  </body>
+</html>`,
+  };
+}
+
+/** Taglia sull'ultimo spazio prima del limite, per non spezzare una parola a metà. */
+function truncate(text: string, max: number): string {
+  const clean = text.trim();
+  if (clean.length <= max) return clean;
+  const cut = clean.slice(0, max);
+  const lastSpace = cut.lastIndexOf(" ");
+  return `${(lastSpace > max * 0.6 ? cut.slice(0, lastSpace) : cut).trimEnd()}…`;
+}
+
 /** Il brand name arriva dal DB ed è admin-controlled, ma finisce in HTML: si sanifica comunque. */
 function escapeHtml(s: string): string {
   return s

src/lib/mentions.ts

@@ -0,0 +1,206 @@
+/**
+ * Menzioni nella chat — «@Nome» dentro il corpo di un messaggio.
+ *
+ * Il modello è deliberatamente senza schema: nessuna tabella `mentions`, nessun
+ * marcatore nel testo. Il body resta esattamente quello che l'admin ha scritto,
+ * e la menzione si riconosce a posteriori confrontando il testo con i nomi noti
+ * del cliente di quella conversazione.
+ *
+ * Perché così e non con un token strutturato tipo `@[Nome](client:id)`:
+ * 1. il testo resta leggibile ovunque finisca — email di notifica, anteprima
+ *    nella lista, log — senza bisogno di un renderer che lo traduca;
+ * 2. sopravvive alla modifica di un messaggio, che qui riscrive il body e non
+ *    saprebbe rigenerare un id nascosto;
+ * 3. non introduce una migration per una funzione che riguarda una sola entità
+ *    (la chat è 1:1, admin ↔ cliente: non esiste "chi" da disambiguare).
+ *
+ * Il prezzo: se il cliente cambia nome, le vecchie menzioni smettono di essere
+ * evidenziate. È un difetto cosmetico e si auto-ripara scrivendo il nome nuovo.
+ *
+ * Funzioni pure: nessun accesso al DB, usabili sia sul server sia nel browser.
+ */
+
+/** Diacritici Unicode combinanti — via da qui, così «Nicolò» matcha «nicolo». */
+const COMBINING = /[\u0300-\u036f]/g;
+/**
+ * Una menzione è delimitata da parola su entrambi i lati:
+ * - a destra, «@Mario» non deve matchare dentro «@Mariotti»;
+ * - a sinistra, la chiocciola deve aprire una parola. Senza questo controllo
+ *   «scrivimi a mario@teckell.it» conterrebbe un tag «@Teckell» e farebbe
+ *   partire una mail di notifica che nessuno ha chiesto.
+ */
+const WORD_CHAR = /[\p{L}\p{N}_]/u;
+
+function foldChar(ch: string): string {
+  const folded = ch.normalize("NFD").replace(COMBINING, "").toLowerCase();
+  // Un carattere può decomporsi in più code point: si tiene il primo, così la
+  // stringa ripiegata resta allineata all'originale posizione per posizione —
+  // che è quello che permette di ritagliare il testo originale dagli indici.
+  return folded.length > 0 ? folded[0] : ch.toLowerCase();
+}
+
+/**
+ * La stessa normalizzazione che usa il parser, esposta per chi deve confrontare
+ * testo digitato con un nome — oggi il filtro del menu nel compositore.
+ *
+ * Va condivisa, non riscritta: con un `toLowerCase()` fatto in casa, digitare
+ * «@nicolo» non troverebbe «Nicolò» nel menu mentre il parser lo riconoscerebbe
+ * benissimo nel messaggio. Due regole diverse per la stessa domanda, e la
+ * seconda si scopre solo quando la mail non parte.
+ */
+export function normalizeForSearch(value: string): string {
+  return Array.from(value).map(foldChar).join("");
+}
+
+/**
+ * Chi si può taggare, e in quanti modi lo si può scrivere.
+ *
+ * La distinzione è il punto di tutto il modulo, ed è quella che il menu del
+ * compositore aveva sbagliato mostrando tre voci per una persona sola:
+ *
+ * - `label` = **chi**. Una riga per destinatario, ed è il testo che finisce nel
+ *   messaggio scegliendolo dal menu.
+ * - `aliases` = **come**. Tutti i modi in cui quel destinatario viene
+ *   riconosciuto rileggendo il testo, perché «@Gian» scritto a mano deve valere
+ *   quanto «@Gian Luca Caruso» scelto dall'elenco.
+ *
+ * Tenendole separate, il giorno in cui i contatti per cliente saranno tre il
+ * menu avrà tre righe e non nove.
+ */
+export type MentionTarget = {
+  /** Il nome che si scrive scegliendolo dal menu. Uno per destinatario. */
+  label: string;
+  /** Ogni forma accettata in lettura, dalla più lunga alla più corta. */
+  aliases: string[];
+};
+
+/**
+ * I destinatari taggabili in questa conversazione.
+ *
+ * Oggi ne esce sempre uno: la chat è 1:1 e `clients` conosce una persona sola.
+ * La forma è già al plurale perché il giorno in cui i contatti diventano righe
+ * a sé (oggi `client_emails` ha gli indirizzi ma non i nomi) qui cambia solo la
+ * query che li carica, non il menu né il parser.
+ */
+export function mentionTargets(client: {
+  name: string;
+  brand_name?: string | null;
+}): MentionTarget[] {
+  const label = client.name.trim();
+  if (!label) return [];
+  return [
+    {
+      label,
+      // Il brand è un alias della persona, non un secondo destinatario: taggare
+      // «@Caruso Speaker» scrive comunque a chi legge quella conversazione.
+      aliases: dedupe([label, client.brand_name ?? "", label.split(/\s+/)[0] ?? ""]),
+    },
+  ];
+}
+
+/**
+ * Tutti gli alias di tutti i destinatari, dal più lungo al più corto: è la lista
+ * che serve al parser. L'ordine conta — «@Mario Rossi» deve vincere su «@Mario»,
+ * altrimenti il chip si fermerebbe a metà del nome.
+ */
+export function mentionAliases(targets: ReadonlyArray<MentionTarget>): string[] {
+  return dedupe(targets.flatMap((t) => t.aliases)).sort((a, b) => b.length - a.length);
+}
+
+/** Scorciatoia per chi deve solo rileggere del testo, senza offrire un menu. */
+export function mentionCandidates(client: {
+  name: string;
+  brand_name?: string | null;
+}): string[] {
+  return mentionAliases(mentionTargets(client));
+}
+
+function dedupe(values: ReadonlyArray<string>): string[] {
+  const seen = new Set<string>();
+  const out: string[] = [];
+  for (const value of values) {
+    const trimmed = value.trim();
+    if (!trimmed) continue;
+    const key = trimmed.toLowerCase();
+    if (seen.has(key)) continue;
+    seen.add(key);
+    out.push(trimmed);
+  }
+  return out;
+}
+
+export type MentionPart =
+  | { type: "text"; value: string }
+  | { type: "mention"; value: string };
+
+/**
+ * Spezza il corpo del messaggio in testo semplice e menzioni, pronte per essere
+ * rese con uno stile diverso. Il valore di una menzione include la chiocciola:
+ * chi lo disegna non deve rimetterla e non deve sapere come è stata trovata.
+ */
+export function splitMentions(body: string, candidates: string[]): MentionPart[] {
+  if (!body) return [];
+  if (candidates.length === 0) return [{ type: "text", value: body }];
+
+  // Si lavora su array di code point, non sulla stringa: gli indici restano
+  // validi anche con emoji o caratteri fuori dal piano base.
+  const chars = Array.from(body);
+  const folded = chars.map(foldChar);
+  const foldedCandidates = candidates.map((c) => Array.from(c).map(foldChar));
+
+  const parts: MentionPart[] = [];
+  let plainFrom = 0;
+  let i = 0;
+
+  while (i < chars.length) {
+    if (chars[i] !== "@") {
+      i++;
+      continue;
+    }
+
+    const before = i > 0 ? chars[i - 1] : undefined;
+    if (before !== undefined && WORD_CHAR.test(before)) {
+      i++;
+      continue;
+    }
+
+    const matched = foldedCandidates.find((cand) =>
+      matchesAt(folded, i + 1, cand)
+    );
+    if (!matched) {
+      i++;
+      continue;
+    }
+
+    const end = i + 1 + matched.length;
+    if (plainFrom < i) {
+      parts.push({ type: "text", value: chars.slice(plainFrom, i).join("") });
+    }
+    parts.push({ type: "mention", value: chars.slice(i, end).join("") });
+    plainFrom = end;
+    i = end;
+  }
+
+  if (plainFrom < chars.length) {
+    parts.push({ type: "text", value: chars.slice(plainFrom).join("") });
+  }
+  return parts;
+}
+
+function matchesAt(
+  folded: string[],
+  start: number,
+  candidate: string[]
+): boolean {
+  if (start + candidate.length > folded.length) return false;
+  for (let k = 0; k < candidate.length; k++) {
+    if (folded[start + k] !== candidate[k]) return false;
+  }
+  const after = folded[start + candidate.length];
+  return after === undefined || !WORD_CHAR.test(after);
+}
+
+/** Questo messaggio tagga il cliente? È il solo interruttore della notifica. */
+export function hasMention(body: string, candidates: string[]): boolean {
+  return splitMentions(body, candidates).some((p) => p.type === "mention");
+}

src/lib/payment-dates.ts

@@ -0,0 +1,100 @@
+// ── Date dei pagamenti, lette come le legge il cliente ───────────────────────
+// Un pagamento ha due date: quella attesa (`due_date`) e quella incassata
+// (`paid_at`). Entrambe sono timestamptz, ma al cliente interessa il giorno sul
+// calendario, non l'istante: "manca una settimana" non deve cambiare risposta
+// perché il container gira a UTC e chi legge sta a Roma.
+//
+// Da qui passeranno anche i promemoria email ("la scadenza si avvicina"): il
+// conteggio dei giorni che decide se mandare la mail deve essere lo stesso
+// numero che il cliente vede nel portale, altrimenti la mail arriva a dire
+// "mancano 3 giorni" mentre il portale ne mostra 2.
+
+/** Il fuso in cui il cliente guarda il calendario. */
+const TZ = "Europe/Rome";
+
+const dayKeyFormatter = new Intl.DateTimeFormat("en-CA", {
+  timeZone: TZ,
+  year: "numeric",
+  month: "2-digit",
+  day: "2-digit",
+});
+
+const longDateFormatter = new Intl.DateTimeFormat("it-IT", {
+  timeZone: TZ,
+  day: "numeric",
+  month: "long",
+  year: "numeric",
+});
+
+const shortDateFormatter = new Intl.DateTimeFormat("it-IT", {
+  timeZone: TZ,
+  day: "numeric",
+  month: "short",
+  year: "numeric",
+});
+
+function toDate(value: Date | string): Date {
+  return value instanceof Date ? value : new Date(value);
+}
+
+/** "2026-03-15" — il giorno civile a Roma, qualunque sia il fuso del server. */
+function dayKey(value: Date | string): string {
+  return dayKeyFormatter.format(toDate(value));
+}
+
+/**
+ * Giorni interi che separano oggi dalla scadenza: 0 = oggi, 3 = fra tre giorni,
+ * -2 = scaduta da due giorni.
+ *
+ * Si confrontano i giorni civili, non gli istanti: una scadenza fissata a
+ * mezzogiorno non deve leggersi "fra 0 giorni" solo perché mancano 20 ore.
+ */
+export function daysUntil(due: Date | string, now: Date = new Date()): number {
+  const a = Date.parse(`${dayKey(now)}T00:00:00Z`);
+  const b = Date.parse(`${dayKey(due)}T00:00:00Z`);
+  return Math.round((b - a) / 86_400_000);
+}
+
+/** "15 marzo 2026" */
+export function formatLongDate(value: Date | string): string {
+  return longDateFormatter.format(toDate(value));
+}
+
+/** "15 mar 2026" — per le righe strette della sidebar. */
+export function formatShortDate(value: Date | string): string {
+  return shortDateFormatter.format(toDate(value));
+}
+
+/**
+ * Il conto alla rovescia in parole. Il ritardo si dice, non si nasconde: una
+ * rata scaduta che continua a mostrare la sua data senza commento sembra a posto.
+ */
+export function formatCountdown(days: number): string {
+  if (days === 0) return "oggi";
+  if (days === 1) return "domani";
+  if (days === -1) return "scaduto da 1 giorno";
+  if (days > 1) return `tra ${days} giorni`;
+  return `scaduto da ${Math.abs(days)} giorni`;
+}
+
+/** Una rata è ancora aperta finché non è saldata — "inviata" non è incassata. */
+export function isOutstanding(status: string): boolean {
+  return status !== "saldato";
+}
+
+type Schedulable = { status: string; due_date: Date | string | null };
+
+/**
+ * La prossima rata da pagare: la più vicina fra quelle aperte che hanno una data.
+ *
+ * Le scadute restano candidate e vincono sulle future — se c'è un arretrato è
+ * quello "il prossimo pagamento", non la rata del mese prossimo.
+ */
+export function findNextDue<T extends Schedulable>(payments: T[]): T | null {
+  const withDate = payments.filter((p) => isOutstanding(p.status) && p.due_date !== null);
+  if (withDate.length === 0) return null;
+
+  return withDate.reduce((earliest, p) =>
+    toDate(p.due_date!).getTime() < toDate(earliest.due_date!).getTime() ? p : earliest
+  );
+}

src/lib/task-status.ts

@@ -6,7 +6,7 @@
 //
 // No db import on purpose: client components import this file.
 
-export const TASK_STATUSES = ["todo", "in_progress", "in_review", "done"] as const;
+export const TASK_STATUSES = ["todo", "in_progress", "in_review", "done", "cancelled"] as const;
 
 export type TaskStatus = (typeof TASK_STATUSES)[number];
 
@@ -15,8 +15,19 @@ export const TASK_STATUS_LABELS: Record<TaskStatus, string> = {
   in_progress: "In corso",
   in_review: "In revisione",
   done: "Fatto",
+  cancelled: "Cancellata",
 };
 
+// Un task cancellato è chiuso, non fatto: resta visibile (barrato) perché il
+// cliente ha il diritto di sapere che quella voce esisteva ed è stata tolta, ma
+// esce dai conteggi. Contarlo nel denominatore bloccherebbe la fase sotto il
+// 100% per sempre; contarlo come fatto racconterebbe una consegna mai avvenuta.
+// Vive qui e non come `!== "cancelled"` sparso nei file: è la stessa disciplina
+// che ha fatto nascere questo modulo.
+export function countsTowardProgress(status: string): boolean {
+  return status !== "cancelled";
+}
+
 export function isTaskStatus(value: string): value is TaskStatus {
   return (TASK_STATUSES as readonly string[]).includes(value);
 }