Vai al contenuto

Audit dipendenze Compila e prova del legacy originale

Esito dell'audit

La separazione precedente era incompleta: gli editor, la gestione NC e le foto chiamavano direttamente il trasporto; il client richiedeva window; il nucleo Python ricavava l'identità del documento dal contesto usato dalla pagina; la classe API renderizzava anche la pagina companion.

Correzioni implementate:

  • Engine, State e Api funzionano con globalThis in assenza di window. Browser e storage offline sono capacità opzionali del trasporto; il motore non richiede un DOM, un renderer o un template.
  • Engine.forConfig restituisce l'istanza condivisa del documento. Editor, NC, foto, AI e controller V3 passano attraverso il motore. Risoluzione URL media e lease fanno parte del contratto del client.
  • _compila_document_metadata fornisce la sola identità dello schema; il nucleo di apertura/salvataggio non costruisce il contesto della pagina o lo stato dei job di stampa.
  • La pagina HTML companion vive in DynamicDocumentBuilderView. Le vecchie route API del QR rinviano alla pagina frontend, conservando i link già distribuiti.
  • Un diniego HTTP 4xx non viene trasformato in apertura dalla cache o salvataggio offline apparentemente riuscito.

Il confine verificato è: interfaccia → client Engine → trasporto HTTP → servizi e adattatori backend. Il core non importa i frontend. Il trasporto continua a gestire sessione, tenant, URL e compatibilità dei link; i servizi conservano gli adattatori allo storage/schema legacy. Questo non significa che l'intero backend sia stato trasformato in un microservizio separato o che ogni funzione storica abbia già un equivalente nel contratto V3.

Evidenze

  • 96 test Python superati: nucleo, runtime, mobile, HTTP e compatibilità del link companion.
  • 14 suite JavaScript superate. tests/js/compila_v3_headless.test.js carica State, Api ed Engine reali, senza window, document o renderer: verifica apertura, sezioni, salvataggi, upload, parcheggio, istanza condivisa e diniego 403 dopo una precedente apertura memorizzata.
  • Controllo automatico delle chiamate: i moduli UI app/edit/media/photo_ai/photo_markup/map non contengono chiamate fetch o ns.Api; le classi API Python non chiamano render_template.
  • Regressione Chromium del V3 corrente: sette risoluzioni da 1920×1080 a 320×568, cambio presentazione, campi non persi, salvataggio, tema, sola lettura e finestre; nessun errore JS.
  • Correzioni motore caricate con riavvio safeops-web.service. Verifiche GET successive: pagina Cassioli e API apertura Cassioli/Orano 200, 400 domande per documento, can_edit=true e readonly=false nel contesto Emma; vecchio link companion 302 verso la pagina frontend, token invalido gestito dalla pagina con 200; login anonimo 200. Nessun RAS modificato.

Replica reale del legacy: prova isolata, non pubblicata

compila_classic_frontend.py utilizza il file originale ras_pack_hotfix35_finalize_zip_c20.html: HTML, CSS, schede, finestre e controller legacy. Non utilizza il renderer o il foglio Classica del V3. Inietta un adattatore frontend compila_v3_legacy_transport.js verso il motore e isola le chiavi della bozza locale dal compilatore storico.

La prova Chromium tests/browser/compila_legacy_transport_probe.py ha aperto il pack reale e visualizzato una sezione/domanda ottenuta tramite il contratto V3, senza chiamate ai vecchi endpoint /ras/api o /dynamic/api e senza errori JavaScript. Screenshot con dati sintetici: /tmp/compila-legacy-real-probe.png.

Questa prova non dimostra la compatibilità funzionale completa e non è raggiungibile da una route pubblica. Restano da completare e verificare:

  • snapshot e ripristini (risposte, revisioni, parcheggio, geolocalizzazione e stato UI hanno semantiche diverse);
  • libretto legacy completo, inclusi campi e metadati che il PATCH V3 non accetta come snapshot;
  • comandi storici ZIP/reset e operazioni specialistiche, stampa e gestione foto su casi reali.

Le operazioni non mappate producono errore esplicito nel prototipo. Gli snapshot non vengono convertiti in un semplice salvataggio risposte: scartare i campi aggiuntivi darebbe un falso esito positivo. Non è stata sostituita la vista pubblica con questo prototipo.

È stata richiesta la scelta di perimetro tra tutte le funzioni legacy e il solo insieme già supportato dal motore V3. Questa scelta riguarda la replica, non l'audit/correzione del confine del motore.

Governance

change_summary: audit e correzione confine motore/frontend; prova isolata sul pack legacy reale
user_impact: motore utilizzabile senza frontend; link companion esistenti mantenuti; replica non ancora pubblicata
roles_impacted: tecnici e profili gia autorizzati
surfaces_impacted: API Compila, editor V3, media, companion foto; prototipo legacy isolato
behavior_change: dinieghi HTTP non mascherati dalla cache; nessun nuovo workflow pubblico
permission_change: nessuna nuova autorizzazione
operator_action_required: nessuna per le correzioni; scelta perimetro per completare la replica
helper_impact: no_helper_impact
helper_content_type: micro_note
release_severity: L1
helper_ready_for_release: true
block_release: false per le correzioni motore; true per la replica legacy
block_reason: replica legacy con snapshot/libretto/operazioni specialistiche ancora da completare

Backup limitato ai file preesistenti di questo intervento: /home/safeops/tmp/compila_true_legacy_20260912/. Nessuna migrazione DB o salvataggio di RAS reali nei test.