141 lines
4.2 KiB
Markdown
141 lines
4.2 KiB
Markdown
# Workflow Pilota - Catasto -> Unita Immobiliari -> Blade NetGescon
|
|
|
|
## Scopo
|
|
|
|
Questo workflow descrive il primo caso operativo da portare nell'interfaccia web del Centro Stella.
|
|
|
|
Caso d'uso: l'operatore vede nella pagina Catasto Hub i dati catastali esterni e vuole confrontarli, abbinarli e aggiornare in modo controllato gli archivi interni delle unita immobiliari, senza rompere le altre Blade che gia leggono quei dati.
|
|
|
|
## Obiettivo funzionale
|
|
|
|
Nella pagina:
|
|
|
|
- `http://192.168.0.205:8000/admin-filament/condomini/catasto-hub`
|
|
|
|
l'operatore deve vedere nella colonna di destra gli archivi interni da aggiornare, usando come riferimento i dati presenti nella vista:
|
|
|
|
- `http://192.168.0.205:8000/admin-filament/condomini/unita-immobiliari`
|
|
|
|
Il sistema deve permettere:
|
|
|
|
1. import preliminare dei dati da VCatasto
|
|
2. abbinamento preliminare con le unita interne
|
|
3. conferma operatore in TAB B
|
|
4. propagazione dei dati confermati alle altre Blade NetGescon
|
|
|
|
## Regola madre dei dati
|
|
|
|
La sorgente di verita interna per le unita deve restare unica e coerente.
|
|
|
|
I dati VCatasto:
|
|
|
|
- integrano
|
|
- propongono
|
|
- arricchiscono
|
|
|
|
ma non devono creare logiche parallele incoerenti con gli archivi interni.
|
|
|
|
## Pipeline funzionale desiderata
|
|
|
|
### TAB A - Pre-aggancio automatico
|
|
|
|
Input:
|
|
- dati importati da API VCatasto
|
|
- archivio interno unita immobiliari
|
|
|
|
Regola di abbinamento preliminare:
|
|
- partire dal campo `indirizzo`
|
|
- estrarre almeno: via, numero civico, scala, interno, piano, subalterno se disponibile
|
|
- confrontare questi elementi con gli archivi interni legacy/core
|
|
- proporre una o piu corrispondenze con stato di confidenza
|
|
|
|
Output TAB A:
|
|
- elenco record catastali
|
|
- proposta di unita interna collegabile
|
|
- stato: associata, non associata, da verificare, soppressa, bene comune non censibile
|
|
|
|
### TAB B - Conferma operatore
|
|
|
|
L'operatore deve poter:
|
|
|
|
- accettare la proposta automatica
|
|
- cambiare manualmente l'unita proposta
|
|
- marcare un caso come non associabile
|
|
- segnalare che il record richiede gestione speciale
|
|
|
|
Output TAB B:
|
|
- associazione confermata
|
|
- dati aggiornabili autorizzati
|
|
- tracciatura di chi ha confermato e quando
|
|
|
|
### Fase successiva - Propagazione controllata
|
|
|
|
Una volta confermata l'associazione:
|
|
|
|
- le altre Blade NetGescon devono leggere il dato consolidato
|
|
- le schermate assemblee e funzioni correlate non devono leggere versioni divergenti dello stesso immobile
|
|
|
|
## Problema attuale da trattare
|
|
|
|
Se si corregge una vista o una logica locale, altre Blade vanno in crisi.
|
|
|
|
Questo indica che manca un punto di consolidamento chiaro tra:
|
|
|
|
- import catasto
|
|
- unita immobiliari interne
|
|
- lettura applicativa dalle altre aree
|
|
|
|
## Decisione architetturale proposta
|
|
|
|
Separare i tre livelli:
|
|
|
|
1. `ingestione catasto`
|
|
2. `matching preliminare`
|
|
3. `unita consolidata leggibile dal resto dell'applicazione`
|
|
|
|
Le altre Blade non devono leggere direttamente il dato grezzo API.
|
|
Devono leggere solo il dato interno consolidato dopo il passaggio TAB A + TAB B.
|
|
|
|
## Cosa deve fare l'interfaccia web del Centro Stella
|
|
|
|
Per questo workflow la UI centrale deve permettere all'operatore di inserire:
|
|
|
|
- URL pagina osservata
|
|
- descrizione del problema
|
|
- esempio record reale
|
|
- risultato atteso
|
|
- JSON API allegato
|
|
- indicazione della Blade o vista se nota
|
|
|
|
Poi il sistema deve produrre automaticamente:
|
|
|
|
1. prompt `.205` per correggere import, matching o vista
|
|
2. prompt `.200` per verificare che la correzione non rompa le altre Blade
|
|
|
|
## Primo lotto minimo da implementare
|
|
|
|
### Lotto 1
|
|
- acquisizione richiesta operatore via web
|
|
- allegato JSON VCatasto
|
|
- collegamento richiesta -> URL pagina -> task `.205`
|
|
|
|
### Lotto 2
|
|
- generazione prompt `.205` e `.200`
|
|
- cronologia esiti e osservazioni
|
|
|
|
### Lotto 3
|
|
- cattura automatica del contesto pagina
|
|
- collegamento a route, Blade, resource Filament e componente Livewire
|
|
|
|
### Lotto 4
|
|
- differenza visiva tra stato attuale e stato atteso
|
|
- promozione in baseline quando `.200` valida
|
|
|
|
## Primo criterio di successo
|
|
|
|
Il flusso e accettabile quando:
|
|
|
|
- l'operatore compila una sola richiesta web
|
|
- non deve copiare a mano prompt separati per `.205` e `.200`
|
|
- il sistema conserva history, allegati e decisioni
|
|
- il dato consolidato delle unita aggiornate resta riusabile dalle altre Blade senza duplicazioni divergenti |