feat(portale): gli stati dei task si distinguono, e "in revisione" dice di chi e' la palla

Nella Timeline — la vista di default — lo stato di un task era solo un cerchietto
colorato: ambra col puntino da 1.5px per "in corso", violetto col puntino da 2px per
"in revisione". A 20px sono lo stesso oggetto. Solo "in revisione" aveva un title; gli
altri tre stati non avevano ne' testo, ne' tooltip, ne' aria-label — l'opposto della
regola UX 3 del design system, che chiede colore + testo, mai colore da solo.

Il punto pero' non era la somiglianza fra i due colori. "In revisione" non significa
quello che dice 5547e55, che lo descriveva come controllo qualita' interno: nel flusso
reale vuol dire "consegnato, aspetta l'OK del cliente". E' uno stato che richiede
un'azione, e per questo un cerchietto muto era il problema vero.

- Le quattro icone si distinguono per forma, non solo per colore, quindi reggono anche
  in bianco e nero e con un daltonismo: vuoto -> punto -> spunta vuota -> spunta piena.
  La spunta compare a lavoro finito e si riempie a lavoro confermato.
- Pill di testo solo su "in corso" e "in revisione". "Da fare" e' un cerchio vuoto e
  "fatto" ha il titolo barrato: etichettarli aggiungeva rumore, non informazione.
- Il conteggio dei task in attesa sta nell'header della fase, quindi si legge anche a
  card chiusa. Serve davvero: l'admin puo' forzare una fase su "completata" dalla
  select, e in quel caso la card parte collassata con dentro la richiesta.
- Legenda + micro-copy sopra entrambe le viste: chi revisiona, e che ogni pagina include
  un giro di revisione — l'informazione commerciale che il cliente non aveva da nessuna
  parte. Rimanda alla chat della fase, che esiste gia'.
- Colonne del kanban cliente colorate con le stesse tinte dell'icona in Timeline: prima
  erano quattro colonne grigie identiche.
- Icona aria-hidden + sr-only, cosi' lo screen reader annuncia lo stato anche sui due
  che non portano la pill.

La barra di avanzamento non e' stata toccata: un task in revisione conta come uno in
corso, cioe' zero. Cambia il tipo di lavoro, non l'avanzamento — gonfiare la percentuale
le avrebbe fatto dire una cosa che il contatore "x di y task" smentiva una riga sotto.

Visual e copy in un solo file, e la legenda si genera da TASK_STATUSES: un quinto stato
non lascera' indietro una lista scritta a mano. Stessa disciplina di 5547e55, nata
proprio perche' due liste fisse avevano fatto sparire dei task senza un errore.

Nessuna migration: e' solo UI.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-22 14:24:35 +02:00
parent c3d2afa61f
commit 2e9bd2ab60
7 changed files with 285 additions and 69 deletions
+10
View File
@@ -389,6 +389,16 @@ 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
**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.
- Sidebar cards (`OffersSection`, `PaymentStatus`, `DocumentsSection`,
`NotesSection`, `TranscriptsSection`) all follow `rounded-xl border-border-light
bg-card shadow-card`.