## Problema Il Convertitore AI genera i form partendo solo dal PDF caricato e dalle regole strutturali del prompt di generazione. Non ha alcuna conoscenza di come OpenCity Italia costruisce i servizi digitali già in produzione: davanti a un modulo di richiesta di accesso agli atti, per esempio, ricostruisce la struttura da zero invece di partire dall'impianto già consolidato per quel tipo di servizio (quali step, quali nested form, quali dichiarazioni, quali allegati). Chi ne è impattato: l'operatore PA che pubblica il servizio. Riceve un form corretto nella forma ma arbitrario nell'impianto, e deve riportarlo a mano sullo standard OpenCity — riordinare gli step, sostituire campi liberi con i nested form corretti, riscrivere le dichiarazioni. Il risultato varia da modulo a modulo anche quando i servizi appartengono alla stessa famiglia. La valutazione automatica lo misura sul KPI 6 (coerenza con il servizio) e sul KPI 8 (logica condizionale). ## Soluzione Come operatore PA, voglio che il form generato parta dalla struttura che OpenCity Italia usa già per quel tipo di servizio, in modo da poterlo pubblicare senza rifarne l'impianto a mano. Aggiungere al contesto di generazione un **catalogo compatto dei servizi digitali OpenCity Italia**, mantenuto in `ai-service` insieme agli altri prompt e accodato al prompt di sistema. Non i JSON completi dei form — consumerebbero troppo contesto, in tensione con la #25 — ma una scheda sintetica per servizio: - nome del servizio - elenco ordinato degli step del wizard - nested form OC utilizzati, indicati per `key` (es. `applicant`, `isee`, `real_estate`) - allegati richiesti e numero di dichiarazioni finali Il prompt istruisce il modello a cercare nel catalogo il servizio più simile al modulo caricato e a usarne l'impianto come base, adattandolo ai campi specifici del PDF. Se nessuna voce è pertinente, la generazione procede come oggi. Il catalogo è un file markdown versionato nel repository: resta leggibile e modificabile dal team senza dipendere da risorse esterne o da URL che possono cambiare, e aggiungere un servizio non richiede modifiche al codice dell'applicazione. **Criteri di accettazione** - Dato un modulo di un servizio presente nel catalogo, il form generato riproduce l'ordine degli step e i nested form previsti da quella scheda, senza che l'operatore debba riorganizzare la struttura. - Dato un modulo di un servizio non presente nel catalogo, la generazione produce comunque un form valido secondo le regole strutturali attuali. - Sul campione della valutazione automatica, i punteggi medi di KPI 6 e KPI 8 sono pari o superiori alla misurazione precedente. - Un membro del team può aggiungere un nuovo servizio al catalogo modificando un solo file, senza toccare il codice dell'applicazione. ## Ambiente di test https://form-ai-qa.opencityitalia.it/ — il caricamento del modulo e l'avvio della generazione avvengono dalla pagina iniziale dell'applicazione. ## Test I test sono automatici: non c'è nulla da eseguire a mano. Il job `test:pdf-evaluation` gira a ogni tag, converte i 50 moduli del campione e produce i punteggi dei KPI, il numero di violazioni strutturali e i tempi di generazione. La verifica di questa issue è il confronto fra due esecuzioni: - `1.8.7-rc.3` — baseline, senza modifiche al contesto - `1.8.7-rc.4` — stesso codice più gli esempi di servizi nel prompt Fra i due tag l'unica differenza è il contenuto aggiunto al prompt, quindi lo scostamento sui KPI è attribuibile solo a questa modifica. I punteggi sono stampati nel log del job, non serve scaricare il report. I tag `1.8.6` e `1.8.7-rc.0`, citati in una versione precedente di questa sezione, non producono dati: in entrambi la valutazione non è mai partita a causa di un difetto nella CI, corretto dalla MR !5. - [ ] Un collega developer confronta i log dei due tag e conferma che KPI 6 e KPI 8 non sono peggiorati ## Documentazione _~~Da aggiungere: link al MR Gitbook~~_