Il form era gia' tokenizzato (~30 var CSS in :root): non riscriviamo nulla,
iniettiamo un blocco di override DOPO il CSS di base, cosi' un errore di
configurazione del merchant non puo' rompere il default.
- theme.ts (modulo PURO, condiviso con la futura anteprima admin): ThemeTokens,
FONT_PRESETS, themeStyle(). Sanificazione a monte: colori solo esadecimali,
raggio e larghezza clampati, font da whitelist, CSS custom con rimozione di
</style, @import, expression(), javascript: e cap a 4000 char.
Derivati: --focus-ring da accent (rgba), --primary-bg-hover per shading.
- recesso.server: tokenizzati anche font (--font) e larghezza (--card-max), che
erano hardcoded; renderShell(inner, theme) inietta l'override; renderStep1..4
accettano e propagano il tema.
- Settings: themeAccent/ButtonBg/ButtonText/Radius/Font/Width/CustomCss + migrazione.
- proxy: loadTheme(shop) in loader e action, propagato ai 22 punti di render.
Nell'early-return senza sessione il tema e' null (non conosciamo lo shop).
fly.toml: min_machines_running resta 0 per scelta (TODO go-live, vedi
PROTECTED-CUSTOMER-DATA.md §5.2).
PROTECTED-CUSTOMER-DATA.md - verdetto: la distribuzione CUSTOM ha accesso
'Always available' a Level 1 e Level 2 (email, statusPageUrl): nessuna approvazione
Shopify da attendere per gli store live. La review servira' per l'app pubblica (R7).
Il fatto che funzioni oggi su pcrt-reso-test non prova nulla: sui development store
la review non e' richiesta comunque.
I requisiti di sicurezza L1/L2 restano pero' obbligatori. Autovalutazione con
evidenze: cifratura a riposo OK (volume Fly ENCRYPTED=true), backup cifrati OK
(snapshot Fly), separazione test/prod OK. Gap: retention non documentata, privacy
policy assente, incident response assente, password Fly da cambiare, snapshot con
sola retention 5gg e nodo singolo (i record legali sono la PROVA del recesso).
fly.toml: min_machines_running 0 -> 1. Un cold start misurato ha richiesto ~38s;
l'art. 54-bis pretende una funzione sempre accessibile e facilmente utilizzabile.
Il tab diceva 'Vuoto = provider di default dell'app', ma questa installazione non
ha secret SMTP_*: vuoto significava 'nessuna ricevuta parte', in silenzio - mentre
CHECKLIST-COMPLIANCE-MERCHANT promette 'ricevuta sempre inviata'.
Il loader ora espone appDefaultSmtp (presenza di SMTP_HOST lato app). Se non c'e'
ne' quello ne' l'SMTP per-shop, banner critico: la ricevuta su supporto durevole
e' un obbligo (art. 54-bis), la funzione non e' conforme finche' non e' configurato.
La dichiarazione e' un campo editabile: il cliente puo' scriverci un intento
parziale (es. 'recedo solo per 2 confezioni su 3'). Finiva nel DB e nella ricevuta
al cliente, ma NON nella notifica al merchant, che agiva senza averla mai letta -
mentre l'app apriva un reso totale. Ora la notifica riporta il testo integrale,
con l'avvertenza di leggerlo prima di agire.
Base legale (ANALISI-REQUISITI-LEGALI.md §5): il considerando 37 della Dir. (UE)
2023/2673 dice che il professionista *can* offrire il recesso su parte del
contratto, non che *deve*. Un pulsante a livello di ordine e' conforme. Ma il form
non lo diceva, mentre le automazioni agivano in modo totale.
- statementTemplate: 'relativo all'INTERO ordine #X' (la dichiarazione ora
corrisponde a cio' che l'app fa davvero).
- SCOPE_HINT sotto la dichiarazione: il recesso riguarda l'intero ordine, per il
parziale contattare il negozio (canale modulo tipo/email, sempre valido).
- Admin: banner quando autoCancelUnfulfilled e' attivo -> annulla e rimborsa
l'INTERO ordine, irreversibile; con ordini multi-articolo meglio tenerlo spento.
- PLAN: A6-ter (recesso parziale) come attivita' OPZIONALE con toggle per-shop
partialWithdrawalEnabled, default OFF. Include la nota che l'idempotenza
(shop, orderId) di fa8ee9c andra' riportata a (shop, orderId, articoli).
- ANALISI-REQUISITI-LEGALI.md §5: punto chiarito + panorama concorrenti (Revize
fa il parziale, Rescindly no, Shopify non ha pulsante nativo, LegalBlink non e'
un concorrente ma un generatore di documenti).
Due difetti sullo stesso endpoint:
1) Nessun controllo duplicati: ogni POST 'confirm' creava una nuova
WithdrawalRequest. Il diritto di recesso si esercita UNA volta per contratto:
una seconda dichiarazione e' senza oggetto e, peggio, inquina l'onere della
prova (N timestamp di trasmissione per un atto che deve averne uno).
Ora: se esiste gia' una richiesta per (shop, orderId) non REJECTED, non se ne
crea una seconda; niente secondo reso, tag, notifica o annullo automatico.
Audit 'withdrawal_duplicate'. La schermata conferma il primo atto col suo
timestamp originale (nessun blocco del flusso: non e' un dark pattern).
Ricevuta re-inviabile al massimo 1 volta/ora (aiuta chi non l'ha ricevuta
senza amplificare), tracciata da audit 'receipt_resent'; il timestamp legale
e receiptSentAt originali non vengono toccati.
2) checkRateLimit era applicato SOLO al case 'lookup'. La conferma era libera:
ogni POST inviava una ricevuta al cliente + una notifica al merchant e
bruciava quota Admin API -> amplificatore di email raggiungibile da chiunque
navighi lo store. Ora e' limitata, con audit 'withdrawal_confirm_rate_limited'.
Spedire da un indirizzo a se stesso via relay esterno (Brevo) viene spesso
scartato dai provider: era il caso in prod (notifyEmail == smtpFrom), la
notifica risultava 'merchant_notified' ma non veniva consegnata.
Il bottone puntava a order.statusPageUrl, cioe' la pagina di stato lato cliente:
inutile per il merchant, che il reso lo gestisce dal pannello. Ora punta a
admin.shopify.com/store/<handle>/orders/<id>, ricavato dal GID dell'ordine.
Etichetta contestuale: 'Gestisci il reso' quando un reso esiste o e' stato creato,
altrimenti 'Apri l'ordine'.
- trySend(): genera un Message-ID nel dominio del From (il default di nodemailer
usa l'hostname del container -> dominio incoerente, segnale antispam).
- CHECKLIST-COMPLIANCE-MERCHANT: l'autenticazione del dominio mittente (SPF/DKIM/
DMARC) e la configurazione SMTP diventano obblighi espliciti del merchant; senza,
la ricevuta durevole non raggiunge il consumatore. Chiarito che l'app la invia
sempre ma la consegna dipende dal provider/dominio del merchant.
Causa reale del mancato invio in prod: Settings aveva porta 587 con 'Connessione
sicura diretta' spuntata -> nodemailer apriva subito TLS su una porta che parla
in chiaro + STARTTLS -> handshake fallito -> receipt_failed.
- buildTransport: secure derivato dalla porta standard (465=true, 587=false),
requireTLS su 587. Su porte non standard resta la scelta del merchant.
- Checkbox 'Connessione sicura' ora dichiara che e' ignorata sulle porte standard.
- Avviso se notifiche attive ma 'Email notifiche' vuota (era null in prod: per
questo non arrivava neanche la notifica al merchant).
- sendTestEmail(): transport.verify() prima dell'invio (errori auth/connessione
espliciti), 1 solo tentativo, ritorna l'errore SMTP grezzo.
- Tab 'Email (SMTP)': campo destinatario + bottone 'Invia email di prova' (usa i
valori del form anche se non salvati; password digitata oppure quella salvata
decifrata). Banner con l'errore esatto.
- Guardia: se Host SMTP e' impostato ma il Mittente (From) e' vuoto, l'invio
fallisce con messaggio chiaro (i provider rifiutano mittenti non verificati)
+ banner di avviso nel tab.
- Audit: receipt_failed / merchant_notify_failed ora salvano l'errore SMTP con
le email mascherate (diagnosticabile, senza PII) invece di una stringa generica.
Sia app embed che app block caricavano il JS con il filtro script_tag (sincrono,
parser-blocking -> warning ParserBlockingScript). Passato a <script defer>.
Il JS ha gia' la guardia window.__recessoModalInit, quindi il doppio caricamento
(embed + block sulla stessa pagina) resta sicuro.
Node 18-alpine non espone 'crypto' come global dichiarato: la libreria
@shopify/shopify-api getCryptoLib() fa 'crypto?.webcrypto' -> ReferenceError
'crypto is not defined' -> validateAppProxyHmac fallisce -> 400 su ogni richiesta
app proxy. Node 22 (come in dev) espone crypto global -> HMAC ok -> 200.
Diagnosi: log Fly mostravano 'crypto is not defined' prima di ogni 400; verificato
con firma app-proxy calcolata a mano (ora 200 + form recesso).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mv83a29B4eFv5ixoj6PoE1
Da review avversariale indipendente:
- Retry invio email (trySend, 3 tentativi backoff) per ricevuta cliente e notifica merchant.
- Webhook GDPR implementati (erano stub) con idempotenza (skip se gia' processed):
* customers/redact: pseudonimizza PII (nome/email/dichiarazione) nelle
WithdrawalRequest del cliente, mantiene il record legale (ordine+timestamp)
come prova art. 54-bis (base art. 17(3) GDPR).
* shop/redact: purge completa dei dati shop (Settings/Exclusion/Withdrawal/
Session/AuditLog + WebhookEvent stale).
* customers/data_request: registra la richiesta + n. record (merchant li recupera
dalla dashboard Recessi).
- Rate-limit: pruning periodico del bucket in-memory (fix memory leak).
- Ricevuta fallita: messaggio di successo onesto (successMessage riceve receipt.ok)
invece del falso 'ti abbiamo inviato la ricevuta'.
- PII: rimossa dai detail audit persistiti degli errori SMTP (ricevuta/notifica).
Non modificati (verificati): off-by-1 finestra = permissivo, non blocca a torto;
'doppio escape' = falso allarme (template e valori escapati una volta ciascuno).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mv83a29B4eFv5ixoj6PoE1
Se l'ordine ha gia' un reso (order.returns), createShopifyReturn ritorna 'exists'
invece di fallire: la notifica dice 'esiste gia' un reso, gestiscilo dall'ordine'
al posto del fuorviante 'reso non creato, fallo manualmente'. Audit shopify_return_exists.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mv83a29B4eFv5ixoj6PoE1
- opTextUnfulfilled / opTextShipped editabili dal merchant, con segnaposto
{{returnAddress}} {{returnCost}} {{orderState}} {{customerName}} {{orderName}}
{{shopName}}. Default = testi attuali. returnCost deriva da returnAtCustomerExpense
(a tuo/nostro carico, Art. 57). returnInstructions deprecato (assorbito da opTextShipped).
- Pagina Impostazioni riorganizzata in 4 tab (Email / Notifiche / Regole recesso /
Reso e stato ordine) + anteprima live del riquadro per stato (non evaso e spedito).
- emailTemplate: renderOperationalBlock ora usa i template + sostituzione segnaposto;
renderOperationalPreview esportato per l'admin. Migrazione op_texts (additiva).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mv83a29B4eFv5ixoj6PoE1
Comportamenti Pizeta-confirmed, tutti toggle per-shop:
- stateAwareEmail (default ON): la ricevuta durevole include un blocco operativo
per stato - non evaso => annullo+rimborso; spedito/consegnato => istruzioni reso
(indirizzo, spese a carico Art.57, prodotto integro, rimborso dopo rientro).
- autoCancelUnfulfilled (default OFF): recesso su ordine non evaso => orderCancel
(refund+restock). Abilita anche lo stop del remarketing via orders/cancelled.
- returnAtCustomerExpense / returnInstructions / returnAddress: config istruzioni reso.
Impl: helper orderState + cancelOrder (recesso.server); renderOperationalBlock +
param operational in renderReceiptHtml (emailTemplate); mailer passa operational;
proxy calcola stato, passa alla ricevuta, auto-annulla; sezione admin 'Reso e stato
ordine'. Migrazione a6bis_state_ops.
+ CHECKLIST-COMPLIANCE-MERCHANT.md: cosa fa l'app vs obblighi del merchant.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mv83a29B4eFv5ixoj6PoE1
Al passo 2 del recesso, se l'ordine risulta gia' annullato (cancelledAt) o
rimborsato/voided (financialStatus), mostra un banner informativo ambra (non
blocca): il recesso resta ammesso (diritto incondizionato + funzione sempre
accessibile Art. 54-bis), ma il consumatore e' informato dello stato.
- recesso.copy: NOTICE.orderClosed.
- recesso.server: noticeBanner + campo notice in renderStep2 + stile .notice ambra con icona.
- proxy: calcola orderClosed al lookup e passa la notice a renderStep2.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mv83a29B4eFv5ixoj6PoE1
Audit AUDIT-STATI-ORDINE.md: matrice stato ordine x normativa (Art. 52/56/57) x
comportamento attuale x gap, con fix prioritizzati.
Fix P1 (correttezza legale):
- G1+G4: la finestra 14gg decorre dalla CONSEGNA (evento fulfillment DELIVERED),
non dalla spedizione (Art. 52 = possesso fisico). Se non consegnato, la finestra
non e' iniziata -> computeDeadline null -> non blocca mai.
- G5: ordini annullati (cancelledAt) o rimborsati/voided (displayFinancialStatus)
-> skip creazione reso (evita doppio reso/rimborso), audit shopify_return_skipped.
- lookupOrder esteso: deliveredAt (da eventi fulfillment), cancelledAt, financialStatus.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mv83a29B4eFv5ixoj6PoE1
Storefront (theme app extension recesso-storefront):
- App block + app embed che linkano a /apps/recesso; modal via iframe con
fallback progressive-enhancement; apertura immediata, dimensione fissa
- Redesign form: pattern modal moderno (header/footer fissi, corpo scorrevole),
modalita' embed, popover info "i", testo ridotto, de-AI, trattini al posto degli em-dash
Ricevuta email:
- Dati per-shop dinamici da Shopify (nome, url, link stato ordine) via getShopInfo + statusPageUrl
- Template editabili VINCOLATI (oggetto/introduzione/nota) con segnaposto; layout
fisso e conforme (dichiarazione, timestamp, avviso art. 54-bis)
- Pagina admin (Polaris) con anteprima live + ripristina default
- Campi email in Settings (Prisma) + migrazioni
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Mv83a29B4eFv5ixoj6PoE1
