Compila RAS v2 - Perimetro pilota Roem

Data: 2026-07-28

Obiettivo

Creare una versione isolata del Compila RAS per pilota Roem, senza sostituire il Compila attuale usato dai tecnici in produzione.

La v2 deve essere uno strumento da campo: compilazione tecnica, foto anche offline, consolidamento dati e preparazione alla stampa. I workflow amministrativi e post-sopralluogo restano fuori.

Principi

• Il Compila attuale resta invariato finche la v2 non e validata.
• La v2 viene attivata solo per tenant/utente/documento pilota.
• Il tecnico deve poter lavorare senza internet.
• I riferimenti local: possono esistere solo sul dispositivo, mai come stato definitivo server.
• Stampa e output tecnici devono partire solo da una bozza server consolidata.
• Firma e consegna restano nella view tecnico esistente, fuori dal pack v2.
• Assemblea e gestione NC completa vengono scorporate.

Moduli del Compila attuale

Modulo	Decisione v2	Note
Schede tecniche RAS	Tenere subito	Core del sopralluogo.
Risposte e note tecniche	Tenere subito	Con autosave locale e sync esplicito.
Foto domanda/scheda	Tenere subito	Deve funzionare offline e consolidare su MinIO quando torna rete.
Gallery sottoschede	Tenere subito, semplificata	Serve ai tecnici, ma con regole piu rigide su ordinamento e stampa.
Libretto dati condominio	Tenere subito	Solo dati necessari al sopralluogo/libretto tecnico.
Companion foto	Tenere nel pilota se stabile	Utile in campo, ma deve rispettare le stesse regole di consolidamento.
Progress compilazione	Tenere subito	Deve indicare anche stato sync/foto.
Preview/stampa bozza	Tenere subito	Solo se non ci sono local: o pending bloccanti.
Firma tecnica	Fuori	Gia gestita nella view tecnico.
Consegna tecnica	Fuori	Gia gestita nella view tecnico.
Assemblea	Scorporare	Contesto amministrativo, non tecnico da campo.
NC workflow	Scorporare	Va nel percorso di risanamento post-RAS.
Interventi/lavori	Rimandare	Se sono proposte tecniche possono rientrare dopo; se sono gestione lavori restano fuori.
DOCX collaborativo	Fuori MVP	Backoffice, non campo.
Admin approval	Fuori	Workflow amministrativo separato.
Export ZIP	Fuori MVP	Utile come diagnostica/admin, non come azione primaria tecnico.
Helper contestuale pesante	Fuori MVP	Da sostituire con micro-stati operativi nel template.
Reset/import storico	Fuori MVP	Solo strumenti admin/diagnostici.

Stati dati richiesti

La v2 deve separare in modo esplicito questi stati:

• locale: dati e foto salvati nel browser, anche offline.
• sync_in_corso: upload foto e salvataggio draft server in corso.
• conflitto: il server ha una revisione diversa e serve una scelta guidata.
• consolidato: nessun local:, nessun pending, draft server allineato.
• non_finalizzabile: esistono foto locali, upload falliti o conflitti.

Regole foto

• Le foto scattate offline restano in IndexedDB finche non vengono caricate.
• Il server non deve salvare local: in legacy_dynamic_answer.
• Il server puo salvare una bozza non consolidata solo se marcata esplicitamente come non finalizzabile.
• Prima di preview/stampa definitiva, la v2 deve verificare assenza di local: in tutto il payload.
• Il consolidamento deve preservare metadati gallery: caption, ordinamento, include in stampa, note.

Migliorie template per uso da campo

La v2 dovrebbe essere piu fluida del template attuale, con meno superfici concorrenti:

• Header compatto con tre stati sempre visibili: rete, sync, consolidamento.
• Barra laterale sezioni piu rapida da scorrere, con stato per sezione: vuota, parziale, completa, foto pending.
• Azione primaria unica: Salva e sincronizza quando online, Salva locale quando offline.
• Pulsante foto sempre vicino alla domanda attiva, senza modal complessi.
• Galleria con ordinamento stabile e thumbnail a dimensione fissa.
• Messaggi brevi e operativi, non testi lunghi di spiegazione.
• Nessun modulo assemblea nel primo viewport.
• Nessun pannello NC nel flusso tecnico.
• Stampa/preview disabilitata con motivo chiaro quando il draft non e consolidato.
• Recupero conflitti in schermata dedicata, non tramite merge silenzioso.

Perimetro MVP Roem

Il primo pilota deve coprire:

1. Apertura Compila v2 su un condominio di prova.
2. Compilazione schede principali.
3. Foto offline in interrato/senza rete.
4. Ritorno online e consolidamento completo.
5. Verifica assenza local: su server.
6. Preview/stampa verticale da bozza consolidata.
7. Riapertura da altro dispositivo con dati allineati.

Entry point tecnico pilota:

• /dynamic/compila-v2/<documento_id>

La rotta e separata da /dynamic/compila/<documento_id> e non sostituisce il Compila attuale.

Feature gate pilota:

• codice feature: feature.compila.ras_v2_pilot
• default: disabilitata
• config opzionale: document_ids/allowed_document_ids, user_ids/allowed_user_ids, usernames/allowed_usernames, emails/allowed_emails

Esempio attivazione tenant/documento/utente:

flask feature_flag_set \
  --tenant-key tenant_netopen \
  --feature-code feature.compila.ras_v2_pilot \
  --enabled \
  --status active \
  --config-json '{"document_ids":[1234],"usernames":["roem"]}'

Criteri di accettazione

• Il tecnico puo completare il sopralluogo senza rete.
• Nessun local: viene salvato come risposta autorevole.
• La v2 blocca stampa/finalizzazione se restano pending o foto locali.
• Draft e risposte server sono coerenti dopo consolidamento.
• Riaprendo il documento da un secondo dispositivo si vedono le stesse foto.
• Il template e utilizzabile su tablet e telefono senza modali o pannelli superflui.

Decisioni aperte

• Companion foto: includerlo nel primo pilota o dopo il consolidamento base?
• Interventi: tenerli come proposta tecnica o spostarli completamente nel risanamento?
• Stampa scheda singola: serve gia in campo o basta preview completa?
• Checkpoint recovery: deve essere visibile al tecnico o solo admin?