netgescon-day0/skill-netgescon/control-tower/CATASTO-UNITA-IMMOBILIARI-WORKFLOW.md

4.2 KiB

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