Compila RAS v2 - Primo audit pilota Roem¶

Data: 2026-07-31

Stato audit¶

Audit operativo sul pilota Roem tenant_netopen, documento RAS demo #7176.

Versione server attesa dal template v2:

compila-v2-roem-pilot-20260731-photo-ledger-off-b15

Nota operativa: nei log del 2026-07-31 risultano ancora tab browser aperte su defer-draft-b7 tramite lease/renew. Per testare b15 serve ricaricare la pagina Compila v2.

Cristallizzato¶

Isolamento v2¶

Entry point separato: /dynamic/compila-v2/<documento_id>.
La v2 non sostituisce /dynamic/compila/<documento_id>.
Template dedicato: app/templates/appbuilder/custom/dynamic_compila_v2.html.
Shell minimale iframe, senza menu AppBuilder completo.
Feature gate pilota previsto da feature.compila.ras_v2_pilot.

Documento pilota Roem¶

Documento pilota: #7176.
Tenant: tenant_netopen.
Cliente pilota: #30546.
Utente pilota: roem.
Permesso di modifica riallineato tramite sorgente commerciale e assegnazione tecnico-commerciale.

Performance boot v2¶

Boot light attivo automaticamente in Compila v2.
UI refresh batch attivo automaticamente in Compila v2.
Prefetch immagini remote disabilitato in Compila v2.
Cleanup IndexedDB spostato fuori dal percorso critico iniziale.
progress non blocca piu il primo render sezione.
draft_load e restore bozza spostati dopo il primo render nella linea defer-draft.

Foto e draft¶

Le foto locali restano marcate come bozza locale finche non vengono consolidate.
Il salvataggio v2 evita di mandare payload con local:, blob: o data: come risposta autorevole.
draft_save v2 porta flag/header dedicati: compila_v2 e X-RAS-Compila-V2.
pushDraftNow() attende il completamento di salvataggi in corso prima di uscire.
Aggiunto forcePhotoDraftPushNow() per forzare la persistenza dopo operazioni foto.
UI diagnostica foto locali/orfane presente: pill locali, dettaglio foto, fix foto da sistemare.

Cancellazione foto¶

Corretto il caso in cui cancellare una foto per key eliminava piu occorrenze uguali.
La cancellazione principale ora usa indice/tessera.
La cancellazione galleria usa id elemento.
La galleria extra domanda non viene piu rimescolata nelle immagini principali dopo la cancellazione.

Stampa e consolidamento¶

La stampa v2 viene bloccata se restano foto locali, pending, conflitti o draft non consolidato.
Prima della stampa viene tentato sync/flush e viene verificata assenza di riferimenti locali.
La gallery extra domanda viene separata dalle immagini principali nel payload di stampa.
Il renderer verticale stampa la galleria extra domanda in fondo alla scheda.

Test coperti¶

Test mirati eseguiti:

pytest -q tests/test_dynamic_gallery_answer_normalization.py tests/test_ras_gallery_print_adapter.py tests/test_ras_gallery_vertical_renderer.py

Risultato:

23 passed

Evidenze operative¶

safeops-web.service: active.
Pack template attuale: photo-ledger-off-b15.
Nei log recenti si vedono rinnovi lease da una tab ancora su defer-draft-b7; non e errore applicativo, ma indica sessione browser non ricaricata.
Verifica DB in sola lettura sul documento #7176:
legacy_dynamic_answer: 952 righe, 952 non vuote.
legacy_dynamic_draft: draft #255, rev=60, aggiornato il 2026-07-30 21:03:11, updated_by_id=2.
Risposte nel draft: 792.
Riferimenti foto lato risposte: 547.
Riferimenti foto lato draft: 283.
Riferimenti locali residui (local:, blob:, data:): 0.
Sono presenti riferimenti remoti duplicati nel documento demo; questo e atteso per il clone/storico e ora la cancellazione b8 agisce sulla singola tessera invece che su tutte le occorrenze dello stesso key.

Intervento performance apertura `open-fast-b9`¶

Osservato su #7176: pagina/pack alle 16:23:56-16:23:57, draft_load alle 16:23:59, prima section loggata alle 16:24:02, poi progress e draft_save alle 16:24:10.
Server non appariva saturo: safeops-web.service attivo e worker web senza CPU alta persistente.
In Compila v2 il restore bozza post-render e stato ritardato a 3 secondi.
In Compila v2 progress, prefetch e sync foto di boot sono ritardati rispetto all'apertura iniziale.
Il persist() di boot in Compila v2 non spinge piu una draft_save automatica senza modifica utente.
Cache-bust template aggiornato a compila-v2-roem-pilot-20260731-open-fast-b9.

Intervento feedback apertura `boot-status-b10`¶

Aggiunta maschera di boot con spinner, barra animata e testo di stato.
Il testo di boot ora indica le fasi principali: inizializzazione, connessione documento, caricamento struttura, preparazione interfaccia e prima scheda.
Durante il cambio/apertura sezione l'area domande mostra uno stato Preparo le domande della scheda... con indicatore animato.
Cache-bust template aggiornato a compila-v2-roem-pilot-20260731-boot-status-b10.

Intervento feedback background `background-status-b11`¶

Aggiunto indicatore non bloccante dopo la comparsa delle schede.
Il badge resta visibile mentre v2 completa riallineamento bozza, aggiornamento avanzamento, prefetch leggero, sync foto e finalizzazione stato UI.
Il badge comunica che le schede sono gia visibili ma il documento sta ancora elaborando in background.
Cache-bust template aggiornato a compila-v2-roem-pilot-20260731-background-status-b11.

Intervento modello foto `photo-ledger-b12`¶

Avviato Step 1 del refactor foto solo per Compila v2.
Aggiunto photo_ledger client-only derivato dal payload legacy.
Il ledger contiene asset foto, assegnazioni e coda operazioni vuota per futura gestione offline.
Snapshot locale e draft server includono photo_ledger solo in v2.
Le strutture legacy (images, detail.image, detail.gallery.items, photo_tray) restano compatibili e non vengono rimosse.
Cache-bust template aggiornato a compila-v2-roem-pilot-20260731-photo-ledger-b12.

Riallineamento modulare `photo-ledger-module-b13`¶

Estratta la logica ledger dal pack monolitico.
Nuovo file dedicato v2: app/static/ras/compila_v2_photo_ledger.js.
Il pack mantiene solo bridge minimi verso window.CompilaV2PhotoLedger.
Il modulo viene caricato solo se la query del pack contiene compila_v2=1.
Cache-bust template aggiornato a compila-v2-roem-pilot-20260731-photo-ledger-module-b13.

Primo cestino logico `photo-trash-b14`¶

Aggiunta operazione modulare trashAssignment() in compila_v2_photo_ledger.js.
Le cancellazioni v2 di foto principali, galleria extra e galleria sottoscheda registrano una assegnazione trash.
In v2 il blob locale IndexedDB non viene eliminato subito quando una foto viene cancellata.
Il cestino e per ora dato interno nel photo_ledger; UI di consultazione/ripristino ancora da fare.
Cache-bust template aggiornato a compila-v2-roem-pilot-20260731-photo-trash-b14.

Rollback operativo ledger `photo-ledger-off-b15`¶

Dopo test reale, il dettaglio risultava lentissimo e la UI foto si riallineava male dopo cancellazione.
Inserito kill-switch: photo_ledger e trash sono spenti sul link normale v2.
Il modulo separato resta nel repo per sviluppo, ma viene caricato solo con query esplicita photo_ledger=1.
Il draft/local snapshot non include piu photo_ledger quando il kill-switch e spento.
Ripristinato comportamento precedente per cancellazione blob locali quando ledger e spento.
Cache-bust template aggiornato a compila-v2-roem-pilot-20260731-photo-ledger-off-b15.

Da verificare con test manuale¶

Ricaricare Compila v2 e verificare che il pack richiesto contenga photo-ledger-off-b15.
Aprire la domanda "Sono presenti aree verdi comuni esterne?".
Aggiungere due foto, idealmente anche con duplicazione controllata dello stesso riferimento.
Cancellare solo l'ultima tessera.
Verificare che sparisca una sola foto.
Salvare/sincronizzare.
Ricaricare la pagina e verificare che lo stato resti coerente.
Generare preview/stampa solo quando non ci sono pending/local.

Cosa manca per dire v2 stabile¶

Test end-to-end browser su apertura, upload foto, cancellazione, refresh e stampa.
Misura reale dei tempi con tab pulita su photo-ledger-off-b15.
Verifica da secondo dispositivo dopo consolidamento.
Verifica offline reale: scatto foto senza rete, ritorno online, sync, refresh.
Test manuale dei conflitti con due tab/dispositivi.
Eventuale cleanup UX: ridurre ulteriormente comandi admin/debug visibili al tecnico.

Stato sintetico¶

La v2 e utilizzabile come pilota tecnico controllato per Roem, con salvataggio bozza, foto, sync e stampa protetta gia impostati. Non e ancora da considerare stabile generale: manca il giro end-to-end documentato su browser reale e secondo dispositivo.