docs: tab pagamenti e riordino task in produzione
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
+6
-5
@@ -4,8 +4,8 @@ milestone: v2.5
|
||||
milestone_name: Audit
|
||||
status: executing
|
||||
stopped_at: "v2.5 in PAUSA. Modifiche hub: A, B, C1 e le due rifiniture del 2026-08-20 in prod; C2 (TidyCal) bloccato sulle credenziali API."
|
||||
last_updated: "2026-08-20T15:40:00.000Z"
|
||||
last_activity: 2026-08-20 -- modifiche hub: rinomina tassonomie e stato task "In revisione" (5547e55)
|
||||
last_updated: "2026-08-20T22:45:00.000Z"
|
||||
last_activity: 2026-08-20 -- tab pagamenti (ordine, rinomina, override) e riordino task (1fa8e1a)
|
||||
progress:
|
||||
total_phases: 4
|
||||
completed_phases: 0
|
||||
@@ -38,6 +38,7 @@ Phase 27 resta a metà — schema e fonti in prod, resto da scrivere.
|
||||
| C2 — TidyCal | ⛔ **[BLOCCANTE]** vedi sotto |
|
||||
| C3 — Alleggerire l'hub | ⏸️ senza perimetro |
|
||||
| Rifiniture — rinomina tassonomie, stato task "In revisione" | ✅ in prod 2026-08-20 |
|
||||
| Tab pagamenti (ordine stabile, rinomina, override) + riordino task | ✅ in prod 2026-08-20, migration `0019` |
|
||||
| D — Whop → audit | ⏸️ dipende dal motore v2.5 |
|
||||
|
||||
Progress: [███░░░░░░░] 25% (v2.5)
|
||||
@@ -72,6 +73,7 @@ Passo per passo in `STATUS.md` e in `…radiant-valley.md`.
|
||||
|
||||
Log completo in `PROJECT.md`. Vive per il lavoro corrente:
|
||||
|
||||
- **[2026-08-20] 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.
|
||||
- **[2026-08-19] L'incassato non attribuibile si mostra, non si spalma** — i pagamenti stanno sul progetto, non sull'offerta. Un progetto senza offerta finisce in una riga "Senza offerta" separata: spalmarlo darebbe un totale che quadra e righe che mentono.
|
||||
@@ -84,9 +86,8 @@ Log completo in `PROJECT.md`. Vive per il lavoro corrente:
|
||||
- **[BLOCCANTE] `LEAD_WEBHOOK_SECRET` non è su Coolify**: finché manca, `/api/webhooks/lead` risponde 403 a tutti (fallimento chiuso voluto). Sblocca: l'utente la imposta.
|
||||
- **Il 100% dell'incassato è "Senza offerta"** — Caruso Speaker e Protocollo Estetico: 5.300 € senza offerte assegnate. Si sistema assegnandole dai rispettivi progetti. Il payload Elementor, intanto, non è ancora verificato sul campo: gestito in modo difensivo, serve un invio vero.
|
||||
- **Il copy fisso del template v1 non ha una fonte nel repo** — il prototipo Giojello non c'è: testi e gerarchia dei blocchi vanno recuperati prima di Phase 30.
|
||||
- **Audit, da vedere sul campo:** il caso "zero dati CrUX" (test 5) e quanto del 52% di checklist non verificabile da HTML statico recuperino gli audit Lighthouse (test 3).
|
||||
- **Whitelist portale vuota per 3 clienti su 4** — si popola da `/admin/clients/<id>`.
|
||||
- **`.env.local` punta al DB di PRODUZIONE**, non allineato a Coolify per `ADMIN_PASSWORD` / `NEXTAUTH_SECRET`.
|
||||
- **Audit, da vedere sul campo:** il caso "zero dati CrUX" (test 5) e quanto del 52% non verificabile da HTML statico recuperi Lighthouse (test 3). **Whitelist portale vuota per 3 clienti su 4** — si popola da `/admin/clients/<id>`.
|
||||
- **`.env.local` punta al DB di PRODUZIONE** (non allineato a Coolify per `ADMIN_PASSWORD`/`NEXTAUTH_SECRET`), e la porta 54321 non è pubblica: per provare in locale serve il tunnel SSH.
|
||||
- **Ogni fase con schema**: migration applicata a prod **prima** del push del codice.
|
||||
- **Debito design (DEBT-01)** — ~40 file, ~450 occorrenze. Dettaglio in `STATUS.md`.
|
||||
|
||||
|
||||
@@ -62,7 +62,32 @@ reale del pannello, nessuna migration (verificato: `tasks.status` è `text` senz
|
||||
lavoro vero non era il nuovo stato ma i tre letterali ricopiati a mano in otto file:
|
||||
ora tutto deriva da `TASK_STATUSES` in `src/lib/task-status.ts`.
|
||||
|
||||
⚠️ **Deployate e servite, non ancora provate a mano.** Build e lint verdi, immagine
|
||||
**In produzione dal 2026-08-20**, secondo giro (`b49d4bf`, `1fa8e1a`, migration `0019`):
|
||||
|
||||
- **Tab pagamenti.** Mettere una rata su "saldato" la faceva saltare in fondo: `payments`
|
||||
non aveva **nessuna** colonna d'ordine e nessuna delle 13 query che la leggono aveva un
|
||||
`ORDER BY`, quindi Postgres restituiva l'ordine fisico e una `UPDATE` in MVCC riscrive la
|
||||
tupla in coda. In produzione **3 progetti su 5 erano già scombinati**. Per questo il
|
||||
backfill della `0019` **non** ordina per `ctid` (avrebbe fotografato lo scombinamento) ma
|
||||
per `percent DESC` con tie su `label`. Ora le rate si rinominano, gli importi si
|
||||
sovrascrivono a mano (`amount_locked` li esclude dal ricalcolo) e lo scarto fra somma
|
||||
rate e totale viene **dichiarato**, non aggiustato di nascosto. Schema a 3 rate: 50/25/25.
|
||||
- **Riordino dei task** dentro la fase, trascinando. `PhasesTab` è un Server Component con
|
||||
closure `"use server"` inline, quindi non è stato convertito: le righe restano
|
||||
server-renderizzate e `SortableTaskList` ci monta attorno solo la maniglia.
|
||||
|
||||
Due bug chiusi per strada, entrambi vivi in produzione: `rescalePayments` azzerava le righe
|
||||
con `percent` NULL appena una riga del progetto ne aveva uno (ed è proprio quello che
|
||||
produce `splitPayment`), e il selettore di schema cancellava `status`/`paid_at` senza
|
||||
chiedere, con due rate già saldate a rischio.
|
||||
|
||||
⚠️ **Provato a runtime, non ancora cliccato.** Build di produzione contro il DB vero via
|
||||
tunnel SSH, in sola lettura: pagina progetto 200, 27 maniglie di trascinamento (esattamente
|
||||
i task delle fasi con più di un task), rate nell'ordine giusto. Restano da esercitare a mano
|
||||
le tre scritture nuove — `reorderTasks`, `updatePaymentField`, `clearPaymentOverride` — e il
|
||||
drag vero e proprio.
|
||||
|
||||
⚠️ **Il giro precedente resta deployato ma non provato a mano.** Build e lint verdi, immagine
|
||||
`9a57e45` viva, `/admin/login` risponde 200. Restano da esercitare in UI le due
|
||||
interazioni: la matita di rinomina con il dialog di conferma, e il drag di un task in
|
||||
"In revisione" con il controllo che la fase risulti *attiva*. Non sono state automatizzate
|
||||
|
||||
Reference in New Issue
Block a user