| name | redazione-pacchetto |
| description | Questa skill deve essere usata quando l'utente vuole "redigere il pacchetto", "creare il pacchetto autorizzativo", "fare la SCIA per iliad", "preparare i documenti del sito", "compilare il pacchetto per il comune", "redigi la SCIA art. 45", "crea i documenti per l'autorizzazione iliad", "fai il pacchetto per [codice sito]", oppure quando fornisce dati di un sito iliad (codice sito, indirizzo, scheda radio, progetto architettonico) chiedendo la redazione completa dei documenti.
|
| metadata | {"version":"0.5.0","author":"K2A s.r.l.s."} |
Redazione Pacchetto Autorizzativo Iliad (SCIA art. 45) — v0.5.0
Redigi il pacchetto autorizzativo completo per una Stazione Radio Base Iliad Italia S.p.A. mediante procedura SCIA ai sensi dell'art. 45 D.Lgs. 259/2003.
FASE 0-BIS — Letture OBBLIGATORIE (non saltare MAI)
Prima di Fase 0 (ricerche web) e di qualsiasi altra operazione, leggere tassativamente e nell'ordine:
references/lezioni-apprese.md — catalogo errori + soluzioni canoniche (L1–L13). Qualsiasi errore già visto in sessioni precedenti è qui. Se lo ripeti, è una tua responsabilità.
references/annotazioni-template.md — classificazione INLINE vs STANDALONE delle annotazioni rosse presenti nei template (evita di cancellare interi paragrafi utili, es. procura Longari)
references/valori-sample-template.md — valori sample realistici nei template che vanno sempre sostituiti (preesistenze SCIA/ARPA/VAP, PRG T4 default, foto sito, ecc.)
references/post-processing.md — procedure tecniche di pulizia finale dei .docx (red-color stripping, sostituzione foto via zipfile, cancellazione aeroporti non pertinenti, rimozione VAP, sanity-check finale)
references/domande-obbligatorie.md — checklist di domande da porre all'utente con AskUserQuestion prima di toccare qualsiasi file
Se NON si leggono questi 5 file, fermarsi e leggerli. È il modo in cui la skill mantiene memoria tra sessioni.
FASE 0-TER — Diagnostica Template
Appena l'utente carica i template .docx, eseguire diagnostica PRIMA di scrivere qualsiasi edit_*.py:
- Lanciare lo script
trova_annotazioni_rosse descritto in annotazioni-template.md su tutti i template caricati, per elencare tutti i pattern rossi presenti
- Listare
word/media/* di ogni template per identificare foto sample da sostituire (criterio: .jpeg > 100KB probabile foto sito; < 20KB probabile logo)
- Confrontare le annotazioni trovate con quelle catalogate in
annotazioni-template.md:
- Se una annotazione è già catalogata → applicare la soluzione canonica (INLINE →
replacements; STANDALONE → annotation_markers)
- Se una annotazione è nuova → chiedere all'utente come gestirla e aggiornare immediatamente
annotazioni-template.md con la nuova voce
FASE 0-QUATER — Checklist Q&A (bloccante)
Prima di scrivere qualsiasi edit_*.py, porre le domande dei blocchi 1–10 di references/domande-obbligatorie.md usando il tool AskUserQuestion.
NON procedere finché:
- Tutti i campi critici (Blocchi 1, 2, 3, 6) sono valorizzati
- L'utente ha confermato esplicitamente la checklist compilata
- Sono stati raccolti tutti i protocolli delle preesistenze (SCIA DPU, ARPA, VAP se applicabile)
- È stata scelta esplicitamente la figura Progettista e, se diverso, il Direttore dei Lavori
- È stato identificato il reference site Alpha24 leggendolo dalla Scheda Radio (mai assumere)
REGOLA ANTI-MEMORIA-CORTA
Se l'utente dice frasi tipo:
- "te lo avevo detto"
- "l'avevamo già risolto"
- "hai dimenticato"
- "ci abbiamo lavorato troppo"
- "ogni volta ripeti gli stessi errori"
→ è un segnale CHIARO che references/lezioni-apprese.md va AGGIORNATO ORA. Aggiungere una nuova voce L-next che cattura il problema, la causa, la regola canonica. Questo è il ciclo di auto-miglioramento del plugin. Non rispondere con scuse: apri il file e aggiungi la voce.
ORDINE DI REDAZIONE DOCUMENTI (VINCOLANTE — vedi L13)
I documenti del pacchetto NON sono indipendenti. Esiste un ordine obbligatorio di redazione perché alcuni documenti derivano da altri:
1. SCIA art. 45 (doc 1)
2. Delega (doc 2)
3. RELAZIONE TECNICA (RT) (doc 4) ← DOCUMENTO MASTER
4. ASSEVERAZIONI (doc 6) ← DERIVA DALLA RT (L13)
5. Atto d'obbligo (doc 10)
6. Dich. Sostitutiva α24h (doc 9)
7. Impegno ARPA (doc 8)
8. B40/RELAIE (doc 7)
Regola L13 — Asseverazioni derivano dalla RT:
- La RT è il documento master: contiene PRG, PTPR, vincoli, ENAC, preesistenze, descrizione intervento nella loro forma canonica.
- Le Asseverazioni riprendono questi stessi valori (cella "relazione precisazioni" C0 P31 + tabella PRG/PTPR/ENAC).
- MAI compilare
edit_asseverazioni.py prima di aver completato e validato edit_rt.py.
- Implementazione:
edit_asseverazioni.py deve usare lo stesso dizionario SITO di edit_rt.py (o rileggere l'output di RT per estrarne i valori canonici).
- Sanity-check incrociato obbligatorio dopo aver generato entrambi: PRG, PTPR, ENAC, vincoli, preesistenze devono essere identici stringa per stringa tra RT e ASSEV. Se c'è una discrepanza → non consegnare il pacchetto.
PRINCIPI FONDAMENTALI (leggere PRIMA di qualsiasi operazione)
Principio 1 — Template Immodificabili
I documenti base del pacchetto (SCIA, Delega, RT, Asseverazioni, Impegno ARPA, Dich. Sostitutiva, Atto d'obbligo) sono template preesistenti che vanno SOLO compilati nelle parti variabili, MAI ricreati da zero.
Regole operative:
- Se l'utente fornisce un file
.docx come template base, quel file va editato, non riscritto
- Per editare un
.docx senza alterare formattazione, stili, intestazioni e piè di pagina, usare il metodo zipfile + XML raw:
- Aprire il
.docx con zipfile in Python
- Leggere
word/document.xml
- Cercare i placeholder o i testi da sostituire con
xml.etree.ElementTree o regex
- Sostituire SOLO le parti variabili (codice sito, nome, indirizzo, catasto, coordinate, ecc.)
- Riscrivere il
.docx con il contenuto XML aggiornato
- NON usare python-docx per riscrivere il documento intero: distrugge la formattazione originale
- Se non è disponibile un template
.docx, generare il documento seguendo fedelmente la struttura in references/struttura-documenti.md
Principio 2 — Checklist Obbligatoria Prima della Compilazione
Prima di toccare qualsiasi template o generare qualsiasi documento, DEVI:
- Identificare tutte le sorgenti dati disponibili:
- Preesistenza (pacchetto già presentato in precedenza per lo stesso sito)
- Scheda Radio (B40/TSSR PDF o FILETX.xlsx)
- Progetto Esecutivo (PE) / Progetto Architettonico
- Input diretto dell'utente
- Compilare la checklist dati (vedi
references/checklist-compilazione-rt.md) verificando per ciascun dato:
- ✅ Trovato → indicare sorgente e valore
- ❌ Non trovato → segnare come
[DA COMPILARE — richiede: descrizione]
- ⚠️ Discordanza tra sorgenti → chiedere all'utente quale valore adottare
- Presentare la checklist compilata all'utente e ottenere conferma PRIMA di procedere alla redazione
Principio 3 — Gerarchia di Prevalenza Dati
Quando lo stesso dato compare in più sorgenti, applicare questa gerarchia:
| Dato | Sorgente prevalente | Fallback |
|---|
| Codice sito e nome sito | Scheda Radio | Preesistenza |
| Indirizzo completo | Preesistenza (se corretta) | PE → Scheda Radio |
| Dati catastali (Foglio, P.lla, Sez.) | Preesistenza | PE |
| Coordinate WGS84 | Scheda Radio | PE |
| Municipio (Roma) | Preesistenza | Verifica web |
| Zona sismica | PE (relazione strutturale) | Preesistenza |
| Destinazione PRG (Tav. 3, 4, G1) | Verifica web PRG Roma | Preesistenza (attenzione: le tavole PRG variano per zona!) |
| Destinazione PTPR (Tav. A, B, C) | Verifica web PTPR Lazio | Preesistenza |
| Vincoli paesaggistici/monumentali | Preesistenza (SOLO da questa sorgente) | — |
| Wording legittimità impianto | Preesistenza (copiare ESATTAMENTE) | — |
| Sistema radiomobile | Scheda Radio | FILETX.xlsx |
| Quota s.l.m. | PE | Scheda Radio |
| Proprietà infrastruttura | Preesistenza | Utente |
| Tipo sito (RT/RL/Palo su edificio) | PE | Preesistenza |
| Tecnico incaricato | Utente | — |
In caso di dubbio su qualsiasi dato → CHIEDERE SEMPRE all'utente.
Principio 4 — La RT è il Documento Master
La Relazione Tecnica (RT) è il documento più completo del pacchetto: contiene tutti i dati identificativi, urbanistici, catastali, tecnici e procedurali del sito. Se la RT è compilata correttamente, tutti gli altri documenti del pacchetto ne derivano senza necessità di richiedere dati aggiuntivi all'utente.
Regole operative:
- Se l'utente fornisce una RT già compilata (anche parzialmente), estraila per prima come sorgente dati primaria per tutti gli altri documenti
- I dati presenti nella RT hanno priorità rispetto all'input diretto dell'utente, tranne in caso di evidente errore
- Quando si completa la RT, automaticamente si hanno i dati per compilare: SCIA, Delega, Asseverazioni, Impegno ARPA, DICH. SOSTITUTIVA, Atto d'obbligo
- Usa la RT anche come checklist di completezza: i campi
[DA COMPILARE] nella RT indicano le lacune da colmare per il pacchetto completo
Fase 0 — Ricerche Web Obbligatorie (SEMPRE all'avvio)
Prima di iniziare la raccolta dati, eseguire ricerche web per aggiornare i componenti variabili del pacchetto. Consultare references/componenti-variabili.md per le query specifiche.
Ricerche obbligatorie:
- PEC destinatari — DPU Roma Capitale, SUAP, Poteri Sostitutivi, Municipio specifico, ARPA Lazio; per comuni fuori Roma: SUAP del comune
- Aggiornamenti normativi — art. 45 D.Lgs. 259/2003, DPCM attuativi L. 214/2023 limiti EM, D.M. 2014 α24h
- Tariffe ARPA Lazio aggiornate per impegno al pagamento
- PRG/PTPR del sito tramite WebGIS Roma o ricerca online (se indirizzo disponibile)
- Validità procura Iliad (Longari, 10/04/2024) — segnalare se prossima alla scadenza
- Nulla Osta Cellnex (se sito in ospitalità) — versione aggiornata
- Regolamento Roma — consultare
references/regolamento-roma.md per verificare: aree preferenziali (Art. 3), divieto siti sensibili (Art. 4), obbligo VAP (Art. 5 co. 5) in base alla zona PRG del sito
Se una ricerca non restituisce risultati certi: usare il valore noto più recente e segnare ⚠️ verifica manuale consigliata.
Fase 1 — Raccolta Dati di Base
Chiedi (o estrai dai file forniti) i seguenti dati minimi obbligatori per iniziare:
- Codice sito (es.
RM00168_005)
- Nome sito (es.
VIA DI TORREVECCHIA)
- Indirizzo (via, numero civico)
- Comune e Municipio (se Roma)
- Dati catastali (Foglio, Particella, Sezione)
- Coordinate WGS84 (Lat N, Long E)
- Data redazione (gg/mm/aaaa)
- Tecnico incaricato (Ing. Luca Rossi o Ing. Jessica Romanelli)
- Sistema radiomobile (es.
5G700/UMTS900/LTE1800/LTE2100/LTE2300/LTE2600/5G3700)
- Quota s.l.m. (quota dell'impianto in metri)
- Tipo sito (Rooftop su edificio / Raw Land / Palo su edificio)
- Proprietà infrastruttura (Cellnex Italia S.p.A. / altro)
Se l'utente fornisce la scheda radio (B40/TSSR PDF o file FILETX.xlsx), estrai da lì i dati tecnici radio (vedi references/dati-sito.md).
Se l'utente fornisce il progetto architettonico (PE), estrai da lì l'indirizzo, i dati catastali, la quota e le coordinate.
Se l'utente fornisce una preesistenza (pacchetto precedente), estrai i dati identificativi, vincoli, wording legittimità e destinazione PRG/PTPR. ATTENZIONE: i vincoli e il wording legittimità vanno presi SOLO dalla preesistenza.
Dopo aver raccolto i dati: compilare e presentare la checklist (references/checklist-compilazione-rt.md) all'utente per conferma.
Fase 2 — Redazione Documenti
Redigi i documenti nell'ordine seguente, usando i template in references/struttura-documenti.md. Per ogni documento:
- Se è disponibile un template
.docx dell'utente: editalo con zipfile/XML (Principio 1)
- Se non è disponibile: genera il file
.docx usando lo skill docx
- Salva ogni file nella cartella di lavoro con la nomenclatura corretta
Ordine di redazione (VINCOLANTE — vedi L13 per la regola RT → ASSEV):
- SCIA art. 45 (doc 1) — documento principale
- Delega alla presentazione (doc 2)
- RT — Relazione Tecnica (doc 4) — DOCUMENTO MASTER: PRG, PTPR, ENAC, vincoli, preesistenze, descrizione intervento nella loro forma canonica. DEVE essere finalizzato prima di procedere alla ASSEV.
- ASSEVERAZIONI (doc 6) — DERIVATO dalla RT: i valori PRG/PTPR/ENAC/vincoli/preesistenze devono coincidere stringa per stringa con la RT.
edit_asseverazioni.py deve usare lo stesso dizionario SITO di edit_rt.py o rileggere l'output della RT.
- Atto d'obbligo (doc 10)
- DICH. SOSTITUTIVA ALPHA24 (doc 9) — reference site SEMPRE da Scheda Radio, mai assumere
- Impegno pagamento ARPA (doc 8)
- B40/RELAIE (doc 7) — richiede dati tecnici radio completi
Sanity-check incrociato RT ↔ ASSEV (obbligatorio): dopo aver generato entrambi i documenti, confrontare PRG, PTPR, ENAC, elenco vincoli, preesistenze SCIA/ARPA/VAP. Se c'è una sola discrepanza → il pacchetto NON è consegnabile.
I documenti 3 (MISE-PROCURA), 5 (PDM) e 13 (Nulla Osta Cellnex) sono file fissi già in formato PDF — non vanno redatti ma solo inclusi nel pacchetto.
Fase 3 — Integrazione Dati Progressiva
Man mano che l'utente fornisce materiali aggiuntivi, aggiorna i documenti:
- Scheda Radio (B40/TSSR PDF) → aggiorna la scheda radio nel B40, le frequenze nella SCIA e nella RT
- FILETX.xlsx → estrai i parametri EM per il B40 (potenze, azimuth, tilt, coordinate punti)
- Progetto Architettonico (PE) → estrai foto del sito, planimetrie, quote edifici per il B40 (sezione 4 e 7.2)
- PDM (Piano di Misurazione ARPA) → includi nel pacchetto come doc 5 senza modifiche
- Misure di campo EM (se fornite) → integra nella sezione 7.2 del B40
- Preesistenza → estrai vincoli, wording legittimità, destinazione PRG/PTPR, dati catastali
Fase 4 — Nomenclatura File
Usa sempre la nomenclatura standard:
[N].[CODICE_SITO]_[NOME_SITO]_[TipoDocumento].docx
Esempi:
1.RM00168_005_VIA DI TORREVECCHIA_Scia art. 45.docx
2.RM00168_005_VIA DI TORREVECCHIA_Delega alla presentazione.docx
4.RM00168_005_VIA DI TORREVECCHIA_RT.docx
6.RM00168_005_VIA DI TORREVECCHIA_ASSEVERAZIONI.docx
7.RM00168_005_VIA DI TORREVECCHIA_B40_RELAIE.docx
8.RM00168_005_VIA DI TORREVECCHIA_Impegno al pagamento art. 45 singolo operatore_Arpa Roma.doc
9.RM00168_005_VIA DI TORREVECCHIA_DICH. SOSTITUTIVA ALPHA24.docx
10.RM00168_005_VIA DI TORREVECCHIA_Atto d'obbligo.docx
Fase 5 — Verifica Finale
Al termine della redazione, prima di consegnare il pacchetto:
- Esegui una verifica incrociata dei dati identificativi tra tutti i documenti generati
- Controlla che tutti i campi
[DA COMPILARE] siano stati risolti
- Verifica la coerenza dei dati con la checklist compilata in Fase 1
- Segnala eventuali dati mancanti che impediscono la finalizzazione
- Verifica che i PEC e i riferimenti normativi siano quelli aggiornati dalla Fase 0
Regole Importanti
- Non inventare dati: se un campo non è disponibile, scrivi
[DA COMPILARE — richiede: descrizione del dato]
- Dati fissi Iliad: usa sempre i dati aziendali fissi in
references/dati-sito.md (CF, sede legale, procura, ecc.)
- Municipio Roma: ricava il Municipio dall'indirizzo o dal codice sito — non assumere; per i comuni fuori Roma omettere il Municipio
- Progettista: usa i dati corretti del tecnico incaricato (Luca Rossi o Jessica Romanelli) da
references/dati-sito.md
- Stralci PRG/PTPR: nella RT sono presenti tabelle PRG/PTPR — le tavole variano per zona della città, verificare sempre con la Fase 0
- Vincoli: i vincoli paesaggistici e monumentali vanno presi ESCLUSIVAMENTE dalla preesistenza
- Wording legittimità: il testo che descrive la legittimità dell'impianto va copiato ESATTAMENTE dalla preesistenza
- Documentazione fotografica: richiede immagini reali del sito — segna come
[INSERIRE FOTO] se non disponibili
- Misure di campo EM: i valori numerici nel B40 (sezione 7.2 e 8) richiedono dati reali delle misure o del software di simulazione
- Template .docx: MAI ricreare da zero un template fornito dall'utente — editare SOLO le parti variabili
- Regolamento Roma: applicare sempre le regole di
references/regolamento-roma.md per siti nel Comune di Roma — verificare aree preferenziali, siti sensibili e necessità VAP
- RT come sorgente dati: se l'utente fornisce una RT, estraila PRIMA di qualsiasi altra operazione e usala come base per tutti gli altri documenti
- RT prima di ASSEV (L13): le Asseverazioni sono un derivato della Relazione Tecnica — mai compilarle prima che la RT sia completa e validata. Vedi
lezioni-apprese.md § L13
- Red stripping obbligatorio nei template RT e ASSEV dopo le sostituzioni — vedi
post-processing.md
- Sostituzione foto sito obbligatoria nel template RT — vedi
post-processing.md § "Sostituzione Foto Sito"
- Reference aeroporto da leggere SEMPRE dal PDM (tavole 7.x), mai assumere — vedi
lezioni-apprese.md § L4
- VAP applicabilità da verificare SEMPRE prima di lasciare riferimenti VAP nei documenti — vedi
lezioni-apprese.md § L10