Orienta B1.10 su Django e allinea versioni

Davide conosce Python: architettura.md §6 documenta l'orientamento su Django (non ancora decisione formale) con le librerie da aggiungere per coda/pianificatore e notifiche in-app; domande- cliente.md e indice-documenti.md allineati. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Riorganizza le spese per certezza e corregge un riferimento a D11 in architettura
2026-09-27 19:41:16 +02:00 · 2026-09-27 19:25:42 +02:00 · 2026-09-27 19:13:30 +02:00 · 2026-09-27 16:59:30 +02:00 · 2026-09-27 16:33:32 +02:00
10 changed files with 1112 additions and 405 deletions
@@ -8,7 +8,7 @@ Gestionale web **multi-ente** per enti del Terzo Settore: uno **studio professio
 Il cliente finanzia il progetto con un **bando a fondo perduto**: il budget è vincolato e il preventivo deve essere **rendicontabile**.
 Autore: Davide, primo preventivo da libero professionista. Sviluppa con Claude come strumento; il costo di Claude Max (90 €/mese × 12 mesi) va nel preventivo.
-**Fase attuale:** analisi dei requisiti. Nessuna scelta tecnica (stack, hosting, fornitori) è ancora presa. Lo stato aggiornato è in `indice-documenti.md` e nella sezione "Stato" di `richiesta.md`.
+**Fase attuale:** analisi dei requisiti. Unica scelta tecnica presa: database PostgreSQL con migrazioni (D12). Stack applicativo, hosting e fornitori non sono ancora scelti: `architettura.md` contiene solo proposte 🔸 da confermare. Lo stato aggiornato è in `indice-documenti.md` e nella sezione "Stato" di `richiesta.md`.
 ## Ruolo di Claude
@@ -21,7 +21,8 @@ Consulente tecnico senior in architettura software, DevOps e preventivazione. Da
 3. **Requisito ambiguo → chiedere prima di procedere**, non indovinare. Se serve andare avanti, scrivere l'ipotesi e segnarla 🔸.
 4. **Aspetti fiscali, contrattuali, privacy e rendicontazione del bando:** dare le informazioni utili, ma ricordare sempre di farle verificare a un **commercialista** o a un **legale**.
 5. **Segnalare i rischi** (scope creep, dipendenze dal cliente, sicurezza dei dati) invece di ometterli per semplificare il preventivo.
-6. **Privacy by design:** il software tratta dati personali di molte persone (soci, volontari, dipendenti), dati antiriciclaggio e possibili dati particolari (art. 9 GDPR). Ogni proposta tecnica va valutata anche sotto questo aspetto.
+6. **Database:** PostgreSQL. Ogni modifica della struttura dei dati si fa con una migrazione versionata insieme al codice, applicata identica in test e produzione; mai modifiche manuali in produzione (D12, RT-16).
 7. **Privacy by design:** il software tratta dati personali di molte persone (soci, volontari, dipendenti), dati antiriciclaggio e possibili dati particolari (art. 9 GDPR). Ogni proposta tecnica va valutata anche sotto questo aspetto.
 ## Formato delle risposte
@@ -34,17 +35,20 @@ Consulente tecnico senior in architettura software, DevOps e preventivazione. Da
 | File | Ruolo |
 |---|---|
-| `fonti/2026-09-25/funzioni software.docx` | Fonte del cliente, citata come **[D]** |
+| `fonti/2026-09-25/funzioni software.docx` | Fonte del cliente, citata come **[D]**. Originale ancora da copiare; nel frattempo vale `funzioni software - testo estratto.md` |
 | `fonti/2026-09-25/Software.xlsx` | Fonte del cliente, citata come **[X]** |
 | `richiesta.md` | **Documento base**: cosa deve fare il software (moduli, RF, RT, dati personali, differenze tra le fonti, decisioni D) |
 | `workflow.md` | Processi del software passo per passo (W), con i riferimenti ai requisiti |
-| `domande-cliente.md` | Tutto ciò che è aperto. Parte A: domande per il cliente (Q) e conferme sui processi · Parte B: dubbi architetturali, rischi, contesto delle domande · Parte C: verifiche con legale e commercialista (**B e C uso interno, non inviare**) |
+| `domande-cliente.md` | Tutto ciò che è aperto. §1 domande essenziali per il cliente (Q) · §2 cose da comunicare al cliente · §3 per Davide: verifiche con legale e commercialista (C), scelte in sospeso (B), domande rimandate, rischi (**§3 uso interno, non inviare**) |
 | `costi-ricorrenti.md` | Costi ricorrenti di sviluppo, test e produzione: prezzi con fonte, scenari, effetti economici delle decisioni |
 | `architettura.md` | Come si costruisce il software: forma dell'applicazione, componenti, dati, permessi, confronto sugli stack, sicurezza, infrastruttura e rilascio (**uso interno**) |
 | `blueprint.md` | Come si organizza la realizzazione: prerequisiti, pacchetti di lavoro (P), tappe di collaudo (T), rischi di pianificazione; base per la stima delle ore (**uso interno**) |
 | `indice-documenti.md` | Versioni in vigore e schema di versione |
 | `invii/` | Copie fisse di ciò che viene preparato o inviato al cliente (es. le domande per il cliente in Markdown); elenco in `indice-documenti.md` §1.3. Non si modificano: una versione nuova è un file nuovo |
 **Nessuna informazione ripetuta:** ogni informazione sta in un solo documento; gli altri la richiamano con il codice (es. "D10", "C7"), senza riscriverla.
-**Dipendenze:** fonti del cliente → `richiesta.md` → workflow, domande, costi.
+**Dipendenze:** fonti del cliente → `richiesta.md` → workflow, domande, costi, architettura → blueprint.
 **Fonti del cliente: cartella `fonti/`.**
 - Ogni consegna del cliente sta in una sottocartella con la data di ricezione: `fonti/AAAA-MM-GG/`. I file mantengono il nome originale.
 - **Non modificare, rinominare o cancellare mai i file in `fonti/`.** Sono le prove di cosa ha chiesto il cliente.
@@ -62,10 +66,12 @@ Consulente tecnico senior in architettura software, DevOps e preventivazione. Da
 | RF-x.y | Requisito funzionale del modulo x | `richiesta.md` §3 |
 | RT-n | Requisito trasversale | `richiesta.md` §4 |
 | Dn | Decisione presa | `richiesta.md` §7 |
-| Qn | Domanda per il cliente | `domande-cliente.md` parte A |
+| Qn | Domanda per il cliente | `domande-cliente.md` §1 |
 | Wn | Workflow | `workflow.md` |
-| Bn.m | Dubbio architetturale (uso interno) | `domande-cliente.md` parte B |
+| Bn.m | Scelta architetturale in sospeso o già orientata (uso interno) | `domande-cliente.md` §3 |
-| Cn | Verifica con legale o commercialista (uso interno) | `domande-cliente.md` parte C |
+| Cn | Verifica con legale o commercialista (uso interno) | `domande-cliente.md` §3 |
 | Pn | Pacchetto di lavoro (uso interno) | `blueprint.md` §2 |
 | Tn | Tappa di collaudo interna | `blueprint.md` §3 |
 **Simboli:** ✅ deciso · ⏳ aperto, da chiedere al cliente · 🔸 ipotesi o passo dedotto, da confermare · ⚖️ da verificare con legale o commercialista.
@@ -95,9 +101,9 @@ I documenti derivati hanno le **stesse X.Y di `richiesta.md`**. I nomi dei file
 **Quando cambia la richiesta** (es. arriva una risposta del cliente):
 1. Aggiornare `richiesta.md`: requisiti coinvolti, eventuale nuova decisione in §7, registro delle modifiche, versione.
-2. Aggiornare i documenti derivati che citano i codici toccati: in `domande-cliente.md` spostare la domanda tra le chiuse (Qn → Dn); in `workflow.md` i passi ⏳ e 🔸 interessati; in `costi-ricorrenti.md` le voci che dipendono dalla risposta.
+2. Aggiornare i documenti derivati che citano i codici toccati: in `domande-cliente.md` spostare la domanda tra le chiuse (Qn → Dn); in `workflow.md` i passi ⏳ e 🔸 interessati; in `costi-ricorrenti.md` le voci che dipendono dalla risposta; in `architettura.md` (§11) e `blueprint.md` (§1.2) le parti che dipendono dalla risposta.
 3. Allineare versioni e registri delle modifiche di tutti i documenti toccati.
 4. Aggiornare `indice-documenti.md`.
 5. Consegnare i file aggiornati e ricordare a Davide di allineare entrambe le copie: cartella locale e documenti del Project su claude.ai.
-**Quando si invia un documento al cliente:** conservarne una copia in `invii/AAAA-MM-GG_<nome>_v<X.Y>.md`, per sapere sempre cosa ha ricevuto. Mai includere la parte B di `domande-cliente.md`.
+**Quando si invia un documento al cliente:** conservarne una copia in `invii/AAAA-MM-GG_<nome>_v<X.Y>.<estensione>` (md, csv…) e registrarla in `indice-documenti.md` §1.3, per sapere sempre cosa ha ricevuto. Mai includere il §3 di `domande-cliente.md`.
@@ -0,0 +1,274 @@
 # Architettura del software
 **Progetto:** Gestionale per enti del Terzo Settore
 **Documento:** `architettura.md`
 **Versione:** 0.4.5 · **Data:** 27/09/2026 · **Stato:** Bozza, proposta da confermare; uso interno
 **Allineato a:** `richiesta.md` v0.4 · **Schema di versione:** vedi `indice-documenti.md`
 **Cosa contiene:** come si costruisce il software: forma dell'applicazione, componenti, dati, permessi, stack, sicurezza, infrastruttura e rilascio. I requisiti non si ripetono: si citano con il codice. Servizi e prezzi di riferimento sono in `costi-ricorrenti.md`, le scelte ancora aperte (B) in `domande-cliente.md` §3, l'ordine di realizzazione in `blueprint.md`.
 Le proposte 🔸 di questo documento diventano decisioni (Dn in `richiesta.md` §7) quando Davide le approva.
 ---
 ## 1. Vincoli di partenza
 Ogni scelta dei paragrafi successivi nasce da uno di questi vincoli.
 | Vincolo | Da dove | Conseguenza per l'architettura |
 |---|---|---|
 | Un solo sviluppatore (Davide, con Claude) | Contesto di progetto | Poche parti in movimento: un'applicazione, un database, strumenti maturi e documentati |
 | Budget vincolato e rendicontabile (bando) | Contesto di progetto | Solo software open source senza licenze; servizi a pagamento solo dove li impone la legge o un requisito (firma, marca, conservazione) |
 | Circa 100 utenti, uso da gestionale d'ufficio | RT-11 (⏳ Q1) | Un server per ambiente basta; nessuna scalabilità orizzontale |
 | Applicazione web da computer | RT-12 | Un'unica interfaccia web; nessuna app, nessun adattamento a smartphone |
 | Ogni ente vede solo i propri dati | RT-1, RT-2, D2 | Separazione per ente nell'applicazione **e** nel database (§4) |
 | PostgreSQL e migrazioni | ✅ D12, RT-16 | Struttura dei dati modificata solo con migrazioni versionate (§4, §8) |
 | Hosting nell'UE | RT-13 | Server e servizi esterni con dati nell'UE |
 | Servizi trasferibili al cliente a fine primo anno | RT-15, D10, D11 | Configurazione descritta nel repository, fornitori che trasferiscono account, nessun servizio difficile da spostare |
 | Valore probatorio dei libri sociali | RF-4.5–4.7, RT-9 | Documenti archiviati non modificabili; registro delle operazioni |
 | Dati personali di molte persone, antiriciclaggio, possibili dati art. 9 | `richiesta.md` §5, RT-10 | Privacy by design (§7) |
 ---
 ## 2. Forma dell'applicazione 🔸 (B2.6)
 ### 2.1 Proposta
 **Un'unica applicazione web** (monolite modulare) con **pagine generate dal server** e interattività leggera nel browser, **un solo database** PostgreSQL e un **processo in background** per i lavori lenti o pianificati.
 - I moduli M1–M9 sono parti separate dello stesso codice e comunicano con chiamate interne, non attraverso la rete.
 - Il processo in background invia le email, chiede firme e marche temporali, genera i PDF e importa i file; il pianificatore lancia alert e solleciti (§3).
 ### 2.2 Perché
 - **RT-11:** con circa 100 utenti un'applicazione su un server regge il carico; nessuna parte deve crescere separatamente dalle altre.
 - **Un solo sviluppatore:** un linguaggio, un rilascio, un registro degli errori.
 - **Natura dei moduli:** schede, tabelle, procedure guidate (RF-6.1, RF-7.1) e flussi di approvazione (RT-3). Non c'è interattività da applicazione (modifica contemporanea, uso offline) che giustifichi un'applicazione browser separata.
 - **RT-15:** un'applicazione sola si documenta e si consegna più facilmente.
 **Eccezione da tenere d'occhio:** se Q19 ha risposta **(c)** (ente e studio lavorano insieme sullo stesso documento), le pagine di M6 e M7 richiedono la modifica contemporanea in tempo reale. La forma dell'applicazione resta la stessa, ma serve un componente in più, da stimare a parte (B1.2).
 ### 2.3 Alternative scartate
 | Alternativa | Perché no |
 |---|---|
 | Microservizi (un servizio per modulo) | Nessun requisito di scalabilità separata; moltiplica rilasci, monitoraggio e punti di guasto per un solo sviluppatore |
 | Applicazione browser separata (SPA) + API | Due applicazioni da sviluppare, versionare e consegnare; nessuna app mobile (RT-12) né API per terzi richieste |
 | Funzioni serverless | Firma, importazione e PDF sono lavori con stato e tentativi ripetuti, più semplici con un processo sempre attivo; legano a un fornitore (RT-15) |
 | Un database per ente | La separazione (RT-1) si ottiene nello stesso database con la row-level security (D12); più database moltiplicano migrazioni (RT-16) e backup |
 **Non si prepara nulla "per il futuro"** (es. più studi sulla stessa piattaforma): D2 prevede un solo studio. Se cambiasse, sarebbe una nuova versione dei requisiti.
 ---
 ## 3. Componenti comuni
 Servono a più moduli e si costruiscono una volta sola (pacchetti P2 e P3 di `blueprint.md`).
 | Componente | Cosa fa | Requisiti | Scelta |
 |---|---|---|---|
 | Accesso | Login, seconda verifica con codice da app (TOTP), recupero password via email. Il referente dell'ente riceve un **link di attivazione a scadenza**, mai una password per email (W1 passo 6) | RT-2, RT-10 | 🔸 Seconda verifica obbligatoria per lo studio (vede tutti gli enti), consigliata per gli enti |
 | Ruoli e permessi | Chi può fare quale azione su quale ente (§5) | RT-1, RT-2 | 🔸 |
 | Flusso di approvazione | Un solo componente a stati per M4, M5 (chiusura annuale), M6 e M7: ammette solo i passaggi di stato previsti e li registra tutti | RT-3; W4, W5, W6, W8 | 🔸 B2.4 |
 | Procedura guidata a sezioni | Compilazione per sezioni, salvataggio di ogni sezione, ripresa del lavoro | RF-5.7, RF-6.1, RF-7.1 | 🔸 |
 | Notifiche | Un solo servizio: scrive la notifica nell'app, mette in coda l'email, registra la lettura. Email senza dati personali, solo un link all'applicazione (§7) | RT-4, RF-8.2 | 🔸 B2.3 |
 | Pianificatore | Alert sulle scadenze di pagamento, alert per il caricamento dei documenti, solleciti | RF-1.9, RF-5.1; W2, W5 | 🔸 |
 | Lavori in background | Esegue i lavori lenti. Se un fornitore non risponde, riprova con attese crescenti e lascia il documento in uno **stato esplicito** (es. "in attesa di firma"), mai a metà | RT-5–RT-8 | 🔸 |
 | Firma elettronica | Componente sostituibile: firma simulata in sviluppo, sandbox del fornitore negli ultimi 40 giorni, fornitore reale in produzione (`costi-ricorrenti.md` §3, nota 3) | RT-5 (⏳ Q4) | ✅ Firma simulata in sviluppo; fornitore: B1.4 |
 | Marca temporale e conservazione | Marca via API sull'impronta del documento. La conservazione digitale è richiesta da [D]: a norma presso un conservatore se Q9 lo richiede, altrimenti archivio interno con marca temporale | RT-6 (⏳ Q9) | B1.4; ⚖️ C4, C6 |
 | Generazione documenti | PDF da modelli HTML per ciò che si stampa (offerte, proforma, libri, verbali, Modello D); Word modificabile per progetti e relazioni, a partire dai modelli del cliente | RT-7, RF-5.7, RF-6.3 (⏳ Q13) | 🔸 Librerie open source dello stack (§6) |
 | Importazione | Excel (🔸 anche CSV, formato non citato nelle fonti) con **mappatura delle colonne salvata per ente e banca**, riusata nei trimestri successivi; controllo riga per riga con l'elenco degli errori, nessuna riga scartata in silenzio; il PDF resta un allegato | RT-8, RF-5.2–5.3 (⏳ Q10) | 🔸 B1.3 |
 | Registro delle operazioni | Chi, cosa, quando, valore prima e dopo, per i dati con valore probatorio e per i dati personali; l'applicazione non lo può modificare | RT-9 | 🔸 B2.5; anche la consultazione dei dati antiriciclaggio (⚖️ C3) |
 | Archivio file | Documenti caricati e generati, fuori dalla cartella dell'applicazione e compresi nei backup; antivirus sui file caricati dagli enti | RT-8, RT-10, RT-15 | 🔸 |
 | Tabelle di configurazione | Valori che lo studio cambia senza sviluppo: catalogo servizi, voci del Modello D, calendario delle scadenze con eccezioni per ente, tariffe orarie del volontariato | RF-1.1, RF-5.1, RF-5.5, RF-9.3 | 🔸 B2.2 |
 ---
 ## 4. Dati
 | Tema | Scelta | Perché |
 |---|---|---|
 | Database | ✅ PostgreSQL, struttura modificata solo con migrazioni | D12, RT-16 |
 | Separazione per ente | ✅ Colonna dell'ente su ogni tabella con dati di un ente, più **row-level security**: il database rifiuta le righe di altri enti anche se l'applicazione sbaglia un filtro. 🔸 L'applicazione imposta l'ente dell'utente all'inizio di ogni transazione e si collega con un utente del database che non è proprietario delle tabelle e non può ignorare la row-level security (altrimenti la protezione non si applica) | RT-1, D12, B2.1 |
 | Persone | 🔸 Una scheda per persona con più ruoli; libro soci e registro volontari fanno riferimento alla scheda | RF-3.3, W3 |
 | Documenti archiviati | 🔸 Nessuna modifica né cancellazione dopo l'archiviazione, bloccata anche nel database (un trigger rifiuta le modifiche alle righe archiviate); correzioni e cessazioni sono nuove voci collegate | W4 passi 5 e 7, RT-9 |
 | Nuove categorie o campi | Con una migrazione | RF-3.2, D12 |
 | Cancellazione di dati personali | Gli utenti si disattivano, non si cancellano: il registro deve poter dire chi ha fatto cosa. Tempi di conservazione degli altri dati personali: ⚖️ C1, C3 | RT-9, RT-10 |
 | Dati in test | Solo dati finti, mai copie della produzione | RT-10 |
 ---
 ## 5. Ruoli e permessi
 - **Due tipi di utente** (D1): **studio** (interno), che vede tutti gli enti, ed **ente** (esterno), legato 🔸 a un solo ente (RT-1).
 - **Permessi per azione, non solo per modulo:** vedere, creare, modificare, inviare in revisione, approvare. Chi fa cosa deriva dalla colonna "Operatore" di [X] e dalle colonne "Chi inserisce" e "Chi controlla" di `richiesta.md` §2; il dettaglio passo per passo è nella colonna "Chi" di `workflow.md`.
 - 🔸 Tra gli utenti dello studio, un ruolo di **amministratore** crea e disattiva gli utenti (W1 passo 6).
 ```mermaid
 flowchart TD
    U[Richiesta di un utente autenticato] --> T{Tipo di utente}
    T -->|studio| S[Tutti gli enti]
    T -->|ente| E[Solo il proprio ente<br/>filtro dell'applicazione + row-level security]
    S --> P{Azione permessa<br/>a questo utente?}
    E --> P
    P -->|sì| OK[Eseguita e registrata<br/>RT-9]
    P -->|no| KO[Rifiutata]
 ```
 ---
 ## 6. Stack applicativo ⏳ B1.10
 Linguaggio e framework non sono ancora scelti. Qui ci sono i criteri, ricavati dai requisiti, e il confronto.
 ### 6.1 Criteri
 | Criterio | Da dove |
 |---|---|
 | Framework "completo": accesso, permessi, migrazioni, coda, pianificatore, email e validazione dei moduli già inclusi | RT-2, RT-4, RT-16, RF-1.9, RF-5.1; un solo sviluppatore |
 | Supporto maturo a PostgreSQL e alla row-level security | D12, RT-1 |
 | Librerie open source per PDF, Word ed Excel | RT-7, RT-8; budget |
 | Diffusione: chi subentra (il cliente, un altro sviluppatore) deve trovare competenze | RT-15; rischio di dipendenza da una sola persona |
 | Conoscenza di Davide | Controllare con competenza il codice scritto con Claude |
 ### 6.2 Confronto
 | | Laravel (PHP) | Django (Python) |
 |---|---|---|
 | Accesso, permessi, migrazioni | Inclusi | Inclusi (i permessi sul singolo record richiedono una libreria) |
 | Coda e pianificatore | Inclusi; la coda può usare PostgreSQL | Con librerie aggiuntive (alcune usano PostgreSQL, altre Redis) |
 | Notifiche nell'app con stato di lettura (RF-8.2) | Incluse (notifiche salvate nel database) | Da sviluppare o con una libreria |
 | Pannello per le tabelle di configurazione (§3) | Con una libreria open source (es. Filament) | Incluso (admin di Django) |
 | PDF / Word / Excel | dompdf o Chrome headless / PHPWord / PhpSpreadsheet | WeasyPrint / python-docx o docxtpl / openpyxl |
 | Pagine dal server con interattività leggera | Blade + Livewire | Template + htmx |
 | Row-level security | Ente impostato a ogni transazione | Stesso meccanismo |
 Rails, .NET e Node.js possono coprire gli stessi requisiti; il confronto si limita alle due opzioni più aderenti ai criteri del §6.1 e si estende se Davide conosce uno di questi stack.
 **Orientamento 🔸 (B1.10):** sui requisiti Laravel e Django si equivalgono; decide la **conoscenza di Davide**, perché nel controllo del codice conta più di qualunque differenza tecnica. Davide conosce Python, non PHP: **Django è l'orientamento attuale**, non ancora deciso (D). I pezzi che Django non include di serie restano piccoli da colmare: coda e pianificatore con Django-Q2 (su PostgreSQL, senza Redis, coerente con il punto sotto) e notifiche con stato di lettura con un modello dedicato o django-notifications-hq; i permessi a livello di singolo record restano comunque affidati alla row-level security di PostgreSQL (D12), non al framework.
 **In entrambi i casi:**
 - 🔸 **niente Redis:** con circa 100 utenti coda e cache sul database bastano, e c'è un servizio in meno da gestire, salvare e trasferire (RT-15). Si aggiunge solo se le misure in produzione lo richiedono;
 - nessun adattamento a smartphone (RT-12).
 ---
 ## 7. Sicurezza e privacy by design
 Per ogni misura: cosa protegge e da quale requisito nasce. ⚖️ Le misure finali dipendono dalle verifiche C1, C2, C3 e C13 (valutazione d'impatto, da chiudere prima dello sviluppo).
 | Misura | Cosa protegge | Rif. |
 |---|---|---|
 | HTTPS su tutto | Dati in transito | RT-10 |
 | Seconda verifica all'accesso (§3) | Account dello studio, che vede tutti gli enti | RT-1, RT-10 |
 | Row-level security (§4) | Dati di un ente dagli utenti di un altro, anche con un errore nel codice | RT-1 |
 | Limite ai tentativi di accesso, sessioni a scadenza | Accessi non autorizzati | RT-10 |
 | Backup cifrati, con una copia fuori dal server (`costi-ricorrenti.md` §3, nota 5) | Perdita o furto dei dati | RT-10, RT-15 |
 | 🔸 Documenti d'identità antiriciclaggio cifrati nell'archivio | Dati antiriciclaggio | ⚖️ C3 |
 | Email, notifiche e log senza dati personali, solo link | Dati che escono dal sistema | RT-4, RT-10 |
 | Monitoraggio degli errori in regione UE, con i dati personali filtrati prima dell'invio (`costi-ricorrenti.md` §3, nota 6) | Dati personali contenuti negli errori | RT-10, RT-13 |
 | Antivirus sui file caricati | Server e utenti dello studio | RT-8 |
 | Test con dati finti ed email intercettate | Persone reali durante i test | RT-10 |
 | Registro delle operazioni (§3) | Valore probatorio, controllo degli accessi | RT-9 |
 | 🔸 Misure aggiuntive per i possibili dati art. 9 | Categorie particolari di dati | ⚖️ C2 |
 | Aggiornamenti di sicurezza di sistema e librerie | Vulnerabilità note | RT-10; dal secondo anno rientra nel contratto di manutenzione separato (D11), termini e ore non ancora decisi |
 ---
 ## 8. Infrastruttura e rilascio
 ### 8.1 Ambienti
 Sviluppo, test e produzione come in `costi-ricorrenti.md` §1, dove sono anche servizi e dimensioni di riferimento.
 🔸 **B2.7: un server per ambiente**, con applicazione, database e processo in background in **container** descritti nel repository (Docker Compose).
 - **RT-16:** test e produzione hanno la stessa configurazione, quindi le migrazioni si applicano identiche.
 - **RT-15:** chi riceve i servizi ricrea l'ambiente dalla configurazione del repository, senza istruzioni a memoria.
 - **Perché non servizi cloud gestiti** (database gestito, container gestiti): con 100 utenti non servono, costano di più con importi meno prevedibili (budget del bando) e legano al fornitore.
 - **Perché non Kubernetes:** serve a coordinare molti server; qui ce n'è uno per ambiente.
 ### 8.2 Ciclo di rilascio
 ```mermaid
 flowchart LR
    A[Sviluppo] --> B[Invio al repository]
    B --> C[Test automatici]
    C -->|falliti| A
    C -->|superati| D[Rilascio in test<br/>con le migrazioni]
    D --> E[Collaudo]
    E -->|problemi| A
    E -->|ok| F[Backup della produzione]
    F --> G[Rilascio in produzione<br/>con le stesse migrazioni]
    G --> H[Verifica dopo il rilascio]
    H -->|errore| I[Ripristino della versione<br/>precedente e del backup]
    H -->|ok| J[Rilascio concluso]
 ```
 - Repository e rilascio automatico sul server Git di Davide (`costi-ricorrenti.md` §3, nota 2).
 - Nessuna correzione a mano in produzione: un errore si corregge con un nuovo rilascio o con il ripristino (RT-16).
 - 🔸 **Prova di ripristino** del backup su un ambiente separato, almeno una volta a trimestre: un backup mai provato non dà garanzie.
 - Monitoraggio di errori e disponibilità: `costi-ricorrenti.md` §3.
 - Le procedure operative (rilascio, ripristino, fornitore che non risponde) si scrivono quando lo stack è scelto: fanno parte del documento di consegna richiesto da RT-15 (P16 in `blueprint.md`).
 ---
 ## 9. Moduli e componenti
 | Modulo | Componenti del §3 | Servizi esterni |
 |---|---|---|
 | M1 Gestione cliente | Generazione documenti, firma, pianificatore, notifiche, configurazione (catalogo) | Firma, email |
 | M2 Anagrafica enti | Registro delle operazioni | — |
 | M3 Anagrafica stakeholder | Registro delle operazioni | — |
 | M4 Libri sociali | Flusso di approvazione, firma (⏳ Q4), marca, conservazione (⏳ Q9), generazione documenti | Firma, marca, conservazione |
 | M5 Contabilità | Importazione, pianificatore, configurazione (Modello D, calendario), procedura guidata, flusso di approvazione, generazione documenti | Email |
 | M6 Progettazione | Procedura guidata, flusso di approvazione (⏳ Q19), generazione Word (⏳ Q13) | — |
 | M7 Rendicontazione sociale | Procedura guidata che legge i dati di M2, M3 e M5 (RF-7.2), flusso di approvazione, generazione documenti | — |
 | M8 Circolari | Notifiche con stato di lettura | Email |
 | M9 Valutazione volontariato | Configurazione (tariffe, ⏳ Q15) | — |
 ---
 ## 10. Fuori perimetro
 Per evitare aggiunte non richieste durante lo sviluppo:
 - app per smartphone e adattamento a schermi piccoli (RT-12);
 - motore di flussi configurabile dall'utente: un solo flusso a stati nel codice (RT-3);
 - firma, marca e conservazione costruite in proprio: servono fornitori qualificati (B1.4, ⚖️ C4);
 - lettura automatica dei PDF finché Q10 non la chiede (B1.3);
 - fattura elettronica sviluppata da zero (B1.5, ⏳ Q5);
 - importazione di dati esistenti all'avvio (RT-14);
 - più lingue, più studi sulla stessa piattaforma (D2), API per terzi: nessun requisito.
 ---
 ## 11. Cosa può cambiare l'architettura
 | Punto aperto | Effetto |
 |---|---|
 | Q1 numero di enti | Dimensione del server di produzione e spazio disco (`costi-ricorrenti.md` §4) |
 | Q4 tipo di firma | Implementazione del componente di firma |
 | Q9, ⚖️ C6 conservazione | Conservatore con o senza API; un archivio o uno per ente; eventuale passo manuale in W4 |
 | Q10 estratti conto PDF | Componente di lettura dei PDF |
 | Q5 fattura elettronica | Integrazione con un servizio esterno |
 | Q13 schema dei progetti | Struttura dei dati di M6 e formato di esportazione |
 | Q19 risposta (c) | Modifica contemporanea in tempo reale per M6 e M7 (§2.2) |
 | ⚖️ C2, C13 | Misure di sicurezza aggiuntive (§7) |
 ---
 ## Registro delle modifiche
 | Versione | Data | Allineato a | Modifiche |
 |---|---|---|---|
 | 0.4 | 27/09/2026 | `richiesta.md` v0.4 | Prima stesura, ricostruita da `architettura.md` e dai §5–6 di `flussi-di-lavoro.md` della cartella `software.old` (24/09/2026). Rispetto all'originale: lo stack passa da scelta fatta a confronto con orientamento (B1.10); codici allineati al repository (RNF → RT, circolari in M8, valutazione del volontariato in M9, fasi secondo D3); tolti Redis, la predisposizione per più studi e l'adattamento a smartphone, che nessun requisito chiede; aggiunti la row-level security (D12), la firma simulata in sviluppo e la risposta (c) di Q19 tra i punti che possono cambiare l'architettura |
 | 0.4.1 | 27/09/2026 | `richiesta.md` v0.4 | Verifica sulle fonti: la conservazione digitale è richiesta da [D], quindi Q9 decide solo se va fatta a norma (prima sembrava facoltativa); il CSV nell'importazione è segnato 🔸 perché le fonti citano solo Excel e PDF |
 | 0.4.2 | 27/09/2026 | `richiesta.md` v0.4 | Nome di M3 allineato a `richiesta.md` v0.4.4 ("Anagrafica stakeholder", da [X]) |
 | 0.4.3 | 27/09/2026 | `richiesta.md` v0.4 | §1: il vincolo "un solo sviluppatore" non indica più chi segue la manutenzione dal secondo anno (richiesta di Davide) |
 | 0.4.4 | 27/09/2026 | `richiesta.md` v0.4 | §7: tolta l'indicazione che D11 decida le "ore di manutenzione" dal secondo anno; D11 decide solo che la gestione tecnica resta a Davide con contratto separato, non termini e ore, ancora aperti |
 | 0.4.5 | 27/09/2026 | `richiesta.md` v0.4 | §6: B1.10 orientata su Django (conoscenza di Davide), non ancora decisione (D); indicate le librerie per colmare coda/pianificatore e notifiche |
 ---
 ## Stato
 - **Fase corrente:** analisi dei requisiti; architettura in bozza v0.4.5.
 - **Decisioni prese:** D12 (PostgreSQL, migrazioni, row-level security); firma simulata in sviluppo (`costi-ricorrenti.md`). B1.10 orientata su Django, non ancora decisione. Il resto è proposta 🔸.
 - **Prossimo passo:** Davide conferma B1.10 (Django) come decisione formale e le proposte 🔸; quelle approvate diventano decisioni in `richiesta.md` §7 (versione 0.5, con allineamento dei documenti derivati).
@@ -0,0 +1,188 @@
 # Blueprint di progetto
 **Progetto:** Gestionale per enti del Terzo Settore
 **Documento:** `blueprint.md`
 **Versione:** 0.4.2 · **Data:** 27/09/2026 · **Stato:** Bozza senza stime; uso interno
 **Allineato a:** `richiesta.md` v0.4 · **Schema di versione:** vedi `indice-documenti.md`
 **Cosa contiene:** come si organizza la realizzazione: prerequisiti, pacchetti di lavoro (P) con le dipendenze, tappe di collaudo interne (T), rischi di pianificazione. È la base per stimare le ore del preventivo, stima non ancora fatta (§6). Cosa si costruisce è in `richiesta.md`, come si costruisce in `architettura.md`, i costi ricorrenti in `costi-ricorrenti.md`.
 ---
 ## 1. Prerequisiti
 ### 1.1 Prima di iniziare lo sviluppo
 | Prerequisito | Perché blocca | Rif. |
 |---|---|---|
 | Vincoli del bando su budget e date | Dicono se perimetro e sequenza del §4 sono compatibili; senza, il piano può essere da rifare | ⚖️ C12 |
 | Requisiti approvati (v1.0) e procedura per le modifiche | Senza un punto fermo ogni richiesta nuova entra nel lavoro senza stima | Q18 |
 | Valutazione d'impatto, se serve | Va fatta prima dello sviluppo e può imporre misure che cambiano la base applicativa (P2) | ⚖️ C13 |
 | Stack applicativo | Serve per impostare il progetto (P1) | B1.10 |
 ### 1.2 Prima di un singolo pacchetto
 Non bloccano l'avvio, ma fermano il pacchetto indicato se arrivano in ritardo.
 | Serve | Per | Rif. |
 |---|---|---|
 | Numero di enti | Dimensionare la produzione (P12) | Q1 |
 | Fase delle circolari | P9 in fase 1 o in fase 2 | Q26 |
 | Qualifica e sezione RUNTS: uno o due campi | Scheda dell'ente (P4) | Q25 |
 | Tipo di firma | Firma reale (P11); fino ad allora firma simulata | Q4 |
 | Conservazione a norma o archivio interno con marca temporale, e a nome di chi | Archiviazione definitiva dei libri (P7, P11) | Q9; ⚖️ C4, C5, C6 |
 | Estratti conto PDF | Importazione (P8) | Q10 |
 | Fattura elettronica | Proforma o integrazione (P6) | Q5 |
 | Schema dei progetti e formato di esportazione | Tutto M6 (P10) | Q13 |
 | Modo di lavoro condiviso | M6 e M7 (P10, P13) | Q19 |
 | Materiali del cliente: modelli di verbale e circolare, estratto conto di esempio per banca, schema del progetto, tariffe orarie | P7 e P9, P8, P10, P14 | `domande-cliente.md` §2 |
 | Sezioni del bilancio sociale, valore delle ore di volontariato | Fase 2 (P13, P14) | Q14, Q15 |
 ---
 ## 2. Pacchetti di lavoro
 La colonna "Ore" resta vuota fino alla stima (§6).
 ### 2.1 Avvio
 | # | Pacchetto | Contenuto | Rif. | Dipende da | Ore |
 |---|---|---|---|---|---|
 | P1 | Impianto del progetto | Repository, test automatici, rilascio automatico, ambienti di test e produzione in container, backup, monitoraggio | `architettura.md` §8; RT-13, RT-15, RT-16 | B1.10 | ⏳ |
 | P2 | Base applicativa | Accesso con seconda verifica, utenti di studio ed ente, ruoli e permessi, separazione per ente con row-level security, registro delle operazioni, notifiche, lavori in background e pianificatore, archivio file con antivirus | `architettura.md` §3–5, §7; RT-1, RT-2, RT-4, RT-9, RT-10 | P1, C13 | ⏳ |
 | P3 | Componenti condivisi | Flusso di approvazione, procedura guidata a sezioni, generazione di PDF e Word, firma simulata, tabelle di configurazione | `architettura.md` §3; RT-3, RT-5, RT-7 | P2 | ⏳ |
 ### 2.2 Fase 1
 | # | Pacchetto | Contenuto | Rif. | Dipende da | Ore |
 |---|---|---|---|---|---|
 | P4 | M2 Anagrafica enti | Scheda dell'ente con le liste chiuse (qualifica, sezione RUNTS, attività art. 5 e 6) | RF-2.1–2.14 | P2 | ⏳ |
 | P5 | M3 Anagrafica stakeholder | Schede persona con più ruoli, controllo dei duplicati, conteggi per M2 | RF-3.1–3.3, W3 | P4 | ⏳ |
 | P6 | M1 Gestione cliente | Catalogo, offerte, firme, scadenziario, proforma, alert | RF-1.1–1.9, W1, W2 | P3, P4 | ⏳ |
 | P7 | M4 Libri sociali | Libro soci, registro volontari, verbali, flusso di approvazione, archiviazione, correzioni come voci collegate | RF-4.1–4.7, W4 | P3, P5 | ⏳ |
 | P8 | M5 Contabilità | Calendario e alert, caricamenti, importazione con mappatura, imputazione sul Modello D, rendiconto, relazione illustrativa | RF-5.1–5.7, W5 | P3, P4 | ⏳ |
 | P9 | M8 Circolari | Scrittura, scelta dei destinatari, invio via email e nell'app, stato di lettura | RF-8.1–8.2, RF-1.10, W7 | P2, P4 | ⏳ |
 | P10 | M6 Progettazione | Procedura guidata a sezioni, lavoro condiviso, esportazione | RF-6.1–6.5, W6 | P3, P4, Q13 | ⏳ |
 | P11 | Servizi esterni reali | Firma del fornitore (sandbox negli ultimi 40 giorni), marche temporali via API, conservazione a norma se richiesta da Q9 | RT-5, RT-6; `costi-ricorrenti.md` §3, nota 3 | P6, P7, Q4, Q9 | ⏳ |
 | P12 | Messa in produzione | Server dimensionato, account dei fornitori intestati a Davide, contratti sul trattamento dei dati, prova di ripristino | RT-11, RT-13, D10; ⚖️ C1 | P8–P11, T4 | ⏳ |
 ### 2.3 Fase 2
 | # | Pacchetto | Contenuto | Rif. | Dipende da | Ore |
 |---|---|---|---|---|---|
 | P13 | M7 Rendicontazione sociale | Procedura guidata precompilata con i dati di M2, M3 e M5 | RF-7.1–7.4, W8 | P3, P5, P8, Q14, Q19 | ⏳ |
 | P14 | M9 Valutazione volontariato | Tariffe per attività, time sheet, valorizzazione delle ore | RF-9.1–9.4, W9 | P3, P5, Q15 | ⏳ |
 ### 2.4 Per tutto il progetto
 | # | Pacchetto | Contenuto | Rif. | Dipende da | Ore |
 |---|---|---|---|---|---|
 | P15 | Collaudo con il cliente | Preparazione e conduzione delle tappe (§3), validazione delle ipotesi 🔸, correzioni che ne derivano | `richiesta.md` §7 | Ogni tappa | ⏳ |
 | P16 | Documento di consegna | Accessi, configurazioni, procedure operative (rilascio, ripristino, fornitore che non risponde) | RT-15; `architettura.md` §8.2 | P12 | ⏳ |
 | P17 | Passaggio dei servizi al cliente | Trasferimento di account, dominio, backup e contratti a fine primo anno | RT-15, D11, B1.9 | P16, Q23 | ⏳ |
 | P18 | Gestione del progetto | Incontri, gestione delle richieste di modifica; 🔸 supporto alla rendicontazione del bando | Q18; ⚖️ C7 | — | ⏳ |
 ---
 ## 3. Tappe di collaudo interne
 Rilasci intermedi **nell'ambiente di test, con dati finti** (RT-10), per far provare il software al cliente mentre si sviluppa. **Non cambiano le fasi** concordate (fase 1 e fase 2, `richiesta.md` §2): servono a validare presto le ipotesi 🔸, quando correggerle costa meno. Le modifiche alla struttura dei dati che ne derivano passano da migrazioni (D12).
 | # | Tappa | Pacchetti | Cosa valida il cliente |
 |---|---|---|---|
 | T1 | Base e anagrafiche | P1–P5 | Accesso, separazione tra enti, schede ente e persona; ipotesi RF-2.13–2.14 e RF-3.3 |
 | T2 | Acquisizione e libri sociali | P6, P7 | W1, W2 e W4 con firma simulata; ipotesi RF-1.1 e passi 🔸 di W1, W2, W4 |
 | T3 | Contabilità e circolari | P8, P9 | W5 e W7; ipotesi RF-5.1 e passi 🔸 di W5, W7 |
 | T4 | Progettazione e servizi reali | P10, P11 | W6, firma reale in sandbox; collaudo finale della fase 1, prima di P12 |
 | T5 | Fase 2 | P13, P14 | W8 e W9 |
 ⚠️ Fino a P11 la firma è simulata e **non ha valore legale**: nessun uso reale del software (offerte vere, libri sociali ufficiali) prima della messa in produzione (P12). Va detto al cliente alla prima tappa.
 ---
 ## 4. Ordine e dipendenze
 ```mermaid
 flowchart LR
    subgraph Avvio
        P1[P1 Impianto] --> P2[P2 Base] --> P3[P3 Componenti]
    end
    subgraph F1[Fase 1]
        P4[P4 M2] --> P5[P5 M3]
        P6[P6 M1]
        P7[P7 M4]
        P8[P8 M5]
        P9[P9 M8]
        P10[P10 M6]
        P11[P11 Servizi reali] --> P12[P12 Produzione]
    end
    subgraph F2[Fase 2]
        P13[P13 M7]
        P14[P14 M9]
    end
    P2 --> P4
    P2 --> P9
    P3 --> P6 & P7 & P8 & P10
    P4 --> P6 & P8 & P9 & P10
    P5 --> P7
    P6 & P7 --> P11
    P8 & P9 & P10 --> P12
    P5 & P8 --> P13
    P5 --> P14
    Q13([Q13 schema progetti]) -.-> P10
    Q4Q9([Q4 · Q9]) -.-> P11
 ```
 **Perché questo ordine:**
 - **M2 per primo:** ogni dato appartiene a un ente (RT-1); senza schede ente non si prova nient'altro.
 - **M3 prima di M4:** libro soci e registro volontari prendono i dati dalle schede persona (RF-3.3 🔸).
 - **M1 dopo i componenti condivisi:** usa la firma (simulata) e la generazione dei documenti.
 - **M5 e M8 non dipendono da M4:** se M4 si ferma su Q9 o C6, si va avanti con loro.
 - **M6 in fondo alla fase 1:** lo schema dei progetti non esiste ancora (RF-6.5, Q13); è il pacchetto più esposto ai ritardi del cliente.
 - **Servizi reali (P11) il più tardi possibile:** la sandbox di firma è gratuita solo per 40 giorni (`costi-ricorrenti.md` §3, nota 3).
 - **M7 dopo M3 e M5:** ne estrae i dati (RF-7.2), quindi la loro struttura deve essere stabile.
 Con un solo sviluppatore i pacchetti vanno in sequenza; il diagramma serve a sapere cosa si può anticipare quando un pacchetto si ferma.
 ---
 ## 5. Rischi di pianificazione
 I rischi generali sono in `domande-cliente.md` §3; qui ci sono solo quelli legati all'ordine e ai tempi.
 | Rischio | Effetto | Come si riduce |
 |---|---|---|
 | Schema dei progetti (Q13) in ritardo | P10 fermo, fase 1 non chiusa | Data di consegna dei materiali nel contratto; M6 in fondo alla fase 1 |
 | Date del bando (C12) incompatibili con la sequenza | Perimetro da ridurre o fase 2 fuori dal bando | C12 prima dell'incontro con il cliente |
 | Integrazione della firma reale più lunga di 40 giorni | +104 € per ogni mese di abbonamento anticipato (`costi-ricorrenti.md` §3, nota 3) | Collaudo con firma simulata (T2); P11 subito prima di P12 |
 | Conservazione a nome di ogni ente o senza API (C6, Q9) | P7 e P11 cambiano (più archivi o un passo manuale) | Chiudere C6 prima del preventivo |
 | Valutazione d'impatto (C13) che chiede misure non previste | P2 da rifare in parte | C13 prima di P2 |
 | Ipotesi 🔸 smentite tardi | Lavoro da rifare | Tappe T1–T5 (§3) |
 ---
 ## 6. Stime (da fare)
 La colonna "Ore" del §2 si compila nel passo successivo, insieme a Davide:
 1. per ogni pacchetto: ore minime e massime, l'assunzione usata e il dato che la verifica;
 2. i pacchetti più incerti si stimano sull'ipotesi dichiarata: P10 e P13 sull'opzione (a) di Q19 (B1.2), P11 sul tipo di firma indicato da Q4 o, senza risposta, su quello più probabile, P7 senza conservazione per ogni ente;
 3. le tariffe orarie le decide Davide;
 4. i costi ricorrenti sono già calcolati a parte (`costi-ricorrenti.md`).
 Prima della stima vanno decise anche B1.11 (guida d'uso e formazione) e B1.12 (correzione dei difetti nel primo anno): nessun requisito nelle fonti, ma cambiano il preventivo.
 ---
 ## Registro delle modifiche
 | Versione | Data | Allineato a | Modifiche |
 |---|---|---|---|
 | 0.4 | 27/09/2026 | `richiesta.md` v0.4 | Prima stesura, ricostruita da `blueprint-progetto.md` e `mvp.md` della cartella `software.old` (24/09/2026). Rispetto all'originale: tolte le stime in settimane e il diagramma temporale (cifre senza dati a supporto; la stima si fa al §6); moduli e fasi allineati a `richiesta.md` v0.4 (circolari M8 in fase 1, M9); prerequisiti riferiti alle domande e alle verifiche attuali (Q, C, B); l'MVP diventa una serie di tappe di collaudo interne, che non cambiano le fasi concordate |
 | 0.4.1 | 27/09/2026 | `richiesta.md` v0.4 | Verifica sulle fonti: la conservazione digitale è richiesta da [D], quindi in §1.2 e P11 si sceglie solo tra conservazione a norma e archivio interno (prima "sì o no") |
 | 0.4.2 | 27/09/2026 | `richiesta.md` v0.4 | Nome di M3 allineato a `richiesta.md` v0.4.4; aggiunte in §1.2 le domande Q25 e Q26 |
 ---
 ## Stato
 - **Fase corrente:** analisi dei requisiti; blueprint in bozza v0.4.2, senza stime.
 - **Decisioni prese:** D1–D13 (`richiesta.md` §7). Ordine dei pacchetti e tappe sono proposte 🔸.
 - **Prossimo passo:** C12 con il commercialista; scelta dello stack (B1.10) e di B1.11, B1.12; poi stima delle ore per pacchetto.
@@ -1,206 +1,207 @@
 # Costi ricorrenti del primo anno
 **Progetto:** Gestionale per enti del Terzo Settore
 **Documento:** `costi-ricorrenti.md`
-**Versione:** 0.3.1 · **Data:** 27/09/2026 · **Stato:** Bozza, da validare
+**Versione:** 0.4.5 · **Data:** 27/09/2026 · **Stato:** Bozza, da validare
-**Allineato a:** `richiesta.md` v0.3 · **Schema di versione:** vedi `indice-documenti.md`
+**Allineato a:** `richiesta.md` v0.4 · **Schema di versione:** vedi `indice-documenti.md`
 ---
-## 1. Scopo e limiti
+## 1. Cosa contiene
-Il documento elenca **tutti gli abbonamenti e i servizi a pagamento ricorrente** (mensili o annuali) necessari per **12 mesi** di progetto, divisi per ambiente:
+Abbonamenti e servizi a pagamento ricorrente per **12 mesi**, divisi in:
 - **sviluppo:** strumenti con cui si scrive il software;
 - **test:** ambiente separato per collaudare con dati finti (RT-10) e far provare le funzioni al cliente;
 - **produzione:** il software in esercizio.
- **Sviluppo:** strumenti con cui si scrive il software;
+**Non contiene:** le ore di lavoro (tariffe decise da Davide) e i costi di Davide come professionista (§7).
 - **Test:** ambiente separato per collaudare senza dati reali;
 - **Produzione:** il software in esercizio, usato dallo studio e dagli enti.
-**Cosa non contiene:**
+**Come leggere i prezzi:**
- le **ore di lavoro** (le tariffe le decide Davide);
+- IVA esclusa, in euro, di listino al **27/09/2026**, con il link alla fonte accanto a ogni voce. Vanno riverificati prima di inviare il preventivo.
- l'hardware (PC di sviluppo) e i costi professionali generali: assicurazione, commercialista, PEC (vedi §8).
+- I listini in dollari sono convertiti al cambio di riferimento **BCE del 25/09/2026: 1 € = 1,1403 USD** ([BCE](https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/eurofxref-graph-usd.en.html)). L'addebito reale dipende dal cambio del giorno.
-
+- I fornitori sono **riferimenti di prezzo, non scelte**: la scelta si fa in fase di architettura, motivata dai requisiti.
-**Regole seguite:**
+- ⚖️ IVA sui servizi esteri e ammissibilità nel bando: C7, C8 (`domande-cliente.md` §3).
 1. **Nessuna cifra inventata.** Ogni prezzo è di listino, con la fonte (§10), verificato il 27/09/2026. Dove il costo dipende da un dato che manca, la voce resta un **parametro**, con l'assunzione dichiarata.
 2. **I fornitori citati sono riferimenti di prezzo, non scelte.** Servono a dare l'ordine di grandezza. La scelta dei fornitori si farà nella fase di architettura, motivata dai requisiti.
 3. **Tutti i prezzi sono IVA esclusa.** Alcuni servizi fatturano in dollari (USD): li lascio in USD per non inventare un tasso di cambio.
 **Chi paga:** decisioni D10 e D11 (`richiesta.md` §7); effetti sui costi al §7.
 ⚖️ IVA sui servizi esteri e ammissibilità nel bando: verifiche C7 e C8 (`domande-cliente.md` parte C).
 ---
 ## 2. Riepilogo
-| Ambiente | Costi certi (12 mesi) | Costi che dipendono da risposte del cliente |
+| | Al mese | 12 mesi |
 |---|---|---|
-| Sviluppo | **1.080,00 €** | — |
+| Sviluppo | 90,00 € | 1.080,00 € |
-| Test | **65,88 €** | — |
+| Test | 5,99 € | 71,88 € |
-| Produzione | **172,65 €** + IPv4 da verificare | Firma elettronica (Q4), marche temporali (volume), conservazione a norma (Q9), fatturazione elettronica (Q5), email e monitoraggio se si superano i piani gratuiti |
+| Produzione | 13,89 € + dominio 11,99 €/anno | 178,65 € |
-| **Totale** | **1.318,53 €** + IVA | Vedi scenari al §6 |
+| **Spese certe** (§3) | | **1.330,53 €** |
 | **Spese da quantificare** (§4) | formule al §4 | 376,00 € nello scenario minimo, 1.902,82 € nell'alto, che non è un massimo (§5) |
-I costi certi sono solo una parte del totale. **La voce più pesante e più incerta è la firma elettronica** (da 360 € a oltre 1.200 € l'anno a seconda del tipo di firma, §5.2). Senza la risposta a Q4 il totale non si può chiudere.
+La voce variabile più pesante è la **firma elettronica**: senza le risposte a Q4 (tipo di firma) e Q1 (numero di enti) il totale non si chiude.
 ---
-## 3. Sviluppo
+## 3. Spese certe
-| Voce | Servizio di riferimento | Canone | 12 mesi | Requisito / motivo | Note |
+| Ambiente | Voce | Servizio di riferimento | Al mese | 12 mesi | Perché | Fonte |
-|---|---|---|---|---|---|
+|---|---|---|---|---|---|---|
-| Assistente di sviluppo | Claude Max | 90,00 €/mese | **1.080,00 €** | Strumento di sviluppo previsto nel contesto di progetto | Cifra indicata da Davide. Il listino ufficiale espone il prezzo in USD ("da $100/mese"): **verificare l'importo in euro sulla prima fattura** |
+| Sviluppo | Assistente di sviluppo | Claude Max | 90,00 € | **1.080,00 €** | Strumento di sviluppo previsto nel progetto | [Anthropic](https://claude.com/pricing) ① |
-| Repository del codice | Server Git di Davide (già attivo) | 0 € | 0 € | Versionamento di codice e documenti | 🔸 Il codice del cliente sta su un server personale: garantire un backup del repository e la continuità del servizio |
+| Sviluppo | Repository del codice e rilascio automatico | Server Git di Davide | 0 € | 0 € | Versionamento di codice e documenti | — ② |
-| Monitoraggio errori | Sentry, piano Developer | 0 € | 0 € | Individuare gli errori prima del cliente | Gratuito: 1 utente, 5.000 errori/mese. Basta finché lavora una sola persona |
+| Test | Server | Hetzner CX23 (2 vCPU, 4 GB, 40 GB), UE | 5,49 € | **65,88 €** | Carico minimo; si può spegnere quando non serve | [Hetzner](https://docs.hetzner.com/general/infrastructure-and-availability/price-adjustment/) · [CostGoat](https://costgoat.com/pricing/hetzner) |
-| Editor, linguaggi, librerie | Strumenti open source | 0 € | 0 € | — | Lo stack non è ancora scelto. Se la scelta richiedesse licenze a pagamento, vanno aggiunte qui |
+| Test | Indirizzo IPv4 | Hetzner | 0,50 € | **6,00 €** | Fatturato a parte | [Hetzner](https://docs.hetzner.com/general/infrastructure-and-availability/ipv4-pricing/) |
 | Test | Firma elettronica | Firma simulata; sandbox del fornitore negli ultimi 40 giorni | 0 € | 0 € | Provare la firma senza pagare l'abbonamento | [Youtrust](https://youtrust.com/pricing-api) · [Youtrust, ambienti](https://developers.youtrust.com/docs/environments-new) ③ |
 | Produzione | Server | Hetzner CX33 (4 vCPU, 8 GB), UE | 8,49 € | **101,88 €** | RT-11, RT-13; margine per generare PDF (RT-7). PostgreSQL (D12) sullo stesso server, senza licenze | [Hetzner](https://docs.hetzner.com/general/infrastructure-and-availability/price-adjustment/) · [CostGoat](https://costgoat.com/pricing/hetzner) ④ |
 | Produzione | Indirizzo IPv4 | Hetzner | 0,50 € | **6,00 €** | Fatturato a parte | [Hetzner](https://docs.hetzner.com/general/infrastructure-and-availability/ipv4-pricing/) |
 | Produzione | Backup del server | Hetzner, 20% del server, 7 copie | 1,698 € | **20,38 €** | Ripristino rapido | [Hetzner](https://docs.hetzner.com/cloud/billing/faq/) |
 | Produzione | Backup esterno | Hetzner Storage Box BX11 (1 TB) | 3,20 € | **38,40 €** | Copia cifrata del database fuori dal server | [remote-backups](https://remote-backups.com/comparison/hetzner-storage-box) · [whtop](https://www.whtop.com/plans/hetzner.com/128269) · [Hetzner](https://www.hetzner.com/storage/storage-box/bx11/) ⑤ |
 | Produzione | Dominio `.it` | Aruba | — | **11,99 €** | Indirizzo del software e mittente email | [Aruba](https://www.aruba.it/listino-domini.aspx) |
 | Produzione | Certificato HTTPS | Let's Encrypt | 0 € | 0 € | Connessione cifrata (RT-10) | [Let's Encrypt](https://letsencrypt.org/) |
 | Produzione | Email | Brevo, piano gratuito (300 email/giorno) | 0 € | 0 € | RT-4, M8; dati nell'UE. Aggiunge il logo Brevo (§4) | [Brevo](https://www.brevo.com/pricing/) · [Brevo, dati](https://help.brevo.com/hc/en-us/articles/360001005510-Data-storage-location) |
 | Sviluppo e produzione | Monitoraggio errori | Sentry Developer (1 utente, 5.000 errori/mese), regione UE | 0 € | 0 € | Errori visti prima del cliente | [Sentry](https://sentry.io/pricing/) · [Sentry, regione UE](https://www.sentry.help/en/articles/13965013-where-are-your-data-servers-located) ⑥ |
 | Produzione | Monitoraggio disponibilità | Uptime Kuma (open source) sul server di Davide | 0 € | 0 € | Avviso se il software non risponde | [Uptime Kuma](https://github.com/louislam/uptime-kuma) ⑦ |
 | | **Totale** | | | **1.330,53 €** | | |
-**Totale sviluppo: 1.080,00 €**
+**Note:**
 1. Cifra indicata da Davide. Il listino è in dollari ("da $100/mese" ≈ 87,70 €): verificare l'importo sulla prima fattura.
 2. 🔸 Il codice del cliente sta su un server personale: servono un backup del repository e la continuità del servizio.
 3. Verificato il 27/09/2026: la sandbox Youtrust è gratuita **solo per 40 giorni**. Dopo resta disponibile **solo con un abbonamento attivo** (104 €/mese, lo stesso della produzione). Le firme di prova non contano nella quota e non hanno valore legale. Per restare a 0 €, il software usa un componente di firma sostituibile: simulato durante lo sviluppo, sandbox reale attivata 40 giorni prima del rilascio. Se servono più giorni: **+104 € per ogni mese** di abbonamento attivato prima della produzione (🔸 da verificare se il piano si paga mese per mese). Confirmo non pubblica condizioni per l'ambiente di prova: chiederle nel preventivo.
 4. 🔸 Dimensionamento: circa 100 utenti con uso da gestionale d'ufficio, quindi pochi utenti contemporanei. Il numero di enti (Q1) può cambiare lo spazio necessario (§4).
 5. Prezzo da due fonti terze (la pagina ufficiale non mostra gli importi); attivazione gratuita secondo whtop. 🔸 Confermare all'ordine. Il backup del database va fatto con copie logiche cifrate verso lo Storage Box, non solo con le copie del server.
 6. La regione UE va scelta alla creazione dell'account: gli errori possono contenere dati personali.
 7. Deve girare **fuori** dal server di produzione, altrimenti non avvisa quando il server è giù.
 **Periodo diverso da 12 mesi:** ogni mese in più o in meno vale la colonna "Al mese" del §2 (produzione solo se già attiva). Dipende da Q23 (§6.3).
 ---
-## 4. Test
+## 4. Spese da quantificare
-**Perché un ambiente separato:** il software tratta dati personali (RT-10). Un ambiente di test separato permette di collaudare con **dati finti**, senza mai usare i dati reali degli enti. Serve anche per far provare al cliente le funzioni prima del rilascio.
+Richieste dal progetto, ma il cui importo non si può ancora scrivere in euro. 🔸 Si dividono in due gruppi: §4.1 quelle legate a un requisito e a una risposta del cliente ancora mancante (Qn), §4.2 quelle facoltative, attivabili con una scelta di Davide indipendente dal cliente. La divisione è un raggruppamento per chiarezza, non cambia nessuna cifra.
-| Voce | Servizio di riferimento | Canone | 12 mesi | Note |
+**Simboli:**
-|---|---|---|---|---|
+- **E** = enti gestiti (Q1);
-| Server di test | Hetzner Cloud CX23 (2 vCPU, 4 GB RAM, 40 GB), Germania/Finlandia | 5,49 €/mese | **65,88 €** | Taglio più piccolo: il carico di test è minimo. Fatturazione oraria, si può spegnere quando non serve |
+- **F** = firme l'anno. 🔸 F = enti che firmano × documenti (offerta, privacy, antiriciclaggio: fino a 3 per ente in W1, più eventuali firme su libri e verbali in W4). Da confermare con il fornitore se conta una firma per documento o per invio;
-| Dominio | Sottodominio del dominio di produzione (es. `test.…`) | 0 € | 0 € | — |
+- **M** = documenti archiviati con marca temporale l'anno (W4, passo 5);
-| Firma elettronica | Ambiente di prova del fornitore (sandbox) | 0 € | 0 € | Il riferimento (Youtrust) offre una sandbox gratuita per 40 giorni. 🔸 Verificare cosa succede dopo: in un anno di sviluppo potrebbe servire un piano a pagamento |
+- **A** = archivi di conservazione: 1 se a nome dello studio, E se a nome di ogni ente (⚖️ C5, C6);
-| Email | Piano gratuito del fornitore | 0 € | 0 € | — |
+- **G** = GB conservati per archivio (arrotondati al GB intero, minimo 1);
 - **D** = GB di spazio disco aggiuntivo.
-**Totale test: 65,88 €** (ipotesi: server acceso tutto l'anno)
+### 4.1 Legate a un requisito, importo aperto in attesa del cliente
 | Voce | Dipende da | Formula (costo annuo) | Fonte |
 |---|---|---|---|
 | Firma semplice (RT-5) | ⏳ Q4, F | **1.248 €** se F ≤ 500 · **1.248 € + 2 € × (F − 500)** se F > 500 | [Youtrust API Plus](https://youtrust.com/pricing-api) ① |
 | Firma qualificata (RT-5) | ⏳ Q4 | firma semplice **+ 10 €** per firma qualificata (pacchetti annuali da almeno 10) oppure **+ 15 €** l'una (da 1 a 9, mensile) | [Youtrust, piani](https://youtrust.com/pricing-application) ② |
 | Firma avanzata (RT-5) | ⏳ Q4 | solo su preventivo | [Youtrust](https://youtrust.com/pricing-api) · [Confirmo](https://www.confirmo.it/prezzi-firma-elettronica-api-confirmo) |
 | Marche temporali via API (RT-6) | M (volume legato a Q1) | lotti: **20 = 6 €** · **100 = 16 €** · **250 = 37,50 €** · **500 = 70 €**; si compra la combinazione più economica. Esempi: M = 120 → 22 €; M = 800 → 118 € | [Openapi, lotti Aruba](https://openapi.com/products/aruba-time-stamps) · [Openapi](https://openapi.com/products/timestamping-services) ③ |
 | Conservazione a norma (RT-6) | ⏳ Q9, A, G | **0 €** se non serve · **A × [49,90 € + 25 € × (G − 1)]** se serve. Esempi: 1 archivio da 3 GB → 99,90 €; 200 archivi da 1 GB → 9.980 € | [Aruba DocFly](https://www.pec.it/docfly-conservazione-digitale-a-norma.aspx) ④ |
 | Fatturazione elettronica | ⏳ Q5 | non quotata | — ⑤ |
 **Note:**
 1. 104 €/mese, 500 firme semplici l'anno incluse. Soglia: 500 firme ≈ 166 enti con 3 documenti. Alternativa: Confirmo da 30 €/mese (360 €/anno), ma firme incluse e costo per firma non sono pubblicati: serve un preventivo.
 2. 🔸 Da confermare se la firma qualificata si somma al piano API o lo sostituisce.
 3. Al server del fornitore si invia solo l'impronta del documento, quindi nessun dato personale esce. Il pacchetto Aruba da 19,90 €/100 ([Ufficio Camerale](https://www.ufficiocamerale.it/marche-temporali/100-marche-temporali-aruba)) si usa solo a mano con ArubaSign, non dal software. 🔸 Verificare con Openapi costi di servizio per richiesta e validità dei lotti.
 4. 49,90 €/anno con 1 GB, 25 €/GB in più; un servizio per partita IVA. ⚠️ Senza API: caricamento manuale (§6.4). Conservatori con API (es. [Namirial](https://partner.namirial.it/conservazione-sostitutiva/)): solo su preventivo.
 5. Se serve, integrazione con un servizio esistente (B1.5).
 ### 4.2 Facoltative, scelta indipendente dal cliente
 | Voce | Dipende da | Formula (costo annuo) | Fonte |
 |---|---|---|---|
 | Email senza logo | volume (Q1), scelta sul logo | **0 €** con il piano gratuito (con logo) · **85,03 €** con Starter annuale ($96,96), 94,71 € se mensile ($9/mese); fino a 5.000 email al mese | [Brevo](https://www.brevo.com/pricing/) · [SMTPedia](https://smtpedia.com/brevo-pricing/) ⑥ |
 | Spazio disco aggiuntivo | D | **0,6864 € × D** (0,0572 € per GB al mese). Esempi: D = 20 → 13,73 €; D = 50 → 34,32 € | [CostGoat](https://costgoat.com/pricing/hetzner) |
 | Monitoraggio errori con più utenti | più persone sul software | **273,61 €** ($26/mese) | [Sentry](https://sentry.io/pricing/) |
 | Monitoraggio disponibilità a pagamento | rinuncia a Uptime Kuma | **126,28 €** ($12/mese, annuale) | [UptimeRobot](https://uptimerobot.com/pricing/) ⑦ |
 **Note:**
 6. 🔸 Consigliato in produzione: le circolari con il logo di un altro marchio non sono professionali. Oltre 5.000 email al mese: piano superiore, da verificare. ⚠️ I prezzi Brevo in euro sono incoerenti tra le fonti, quindi si usa il listino ufficiale in dollari.
 7. Il piano gratuito di UptimeRobot è indicato "per progetti hobby e non profit": per un servizio professionale meglio non contarci.
 **Totale annuo = 1.330,53 € (§3) + §4.1 (firma + marche + conservazione [+ fatturazione elettronica]) + §4.2 se attivate (email + disco [+ monitoraggio a pagamento]).**
 ---
-## 5. Produzione
+## 5. Scenari
-### 5.1 Costi certi
+### 5.1 Minimo e alto
-**Ipotesi di dimensionamento (🔸):** circa 100 utenti (RT-11) con un uso da gestionale d'ufficio: pochi utenti contemporanei. Un server virtuale di taglio medio basta, con database sullo stesso server. Il numero di enti (Q1) può cambiare questa ipotesi: più documenti archiviati significano più spazio.
+| Voce | Minimo | Alto |
 | Voce | Servizio di riferimento | Canone | 12 mesi | Requisito / motivo |
 |---|---|---|---|---|
 | Server di produzione | Hetzner Cloud CX33, Germania/Finlandia | 8,49 €/mese | **101,88 €** | RT-11 dimensionamento; RT-13 hosting UE. Un taglio sopra quello di test, per avere margine sulla generazione di PDF (RT-7) |
 | Backup del server | Backup Hetzner (20% del prezzo del server, 7 copie) | 1,698 €/mese (20% di 8,49 €) | **20,38 €** | Ripristino rapido in caso di guasto |
 | Backup esterno | Hetzner Storage Box BX11 (1 TB) | 3,20 €/mese 🔸 | **38,40 €** | Copia dei dati fuori dal server (regola 3-2-1). 🔸 Prezzo da fonte terza, da verificare sul listino dopo gli aumenti di giugno 2026 |
 | Dominio | Dominio `.it` | 11,99 €/anno | **11,99 €** | Indirizzo del software e mittente delle email |
 | Indirizzo IPv4 | Hetzner Primary IPv4 | 🔸 da verificare | 🔸 | Hetzner lo fattura come voce separata: importo da leggere nel configuratore |
 | Certificato HTTPS | Let's Encrypt | 0 € | 0 € | Connessione cifrata (GDPR, RT-10) |
 | Email (alert e circolari) | Brevo, piano gratuito (300 email/giorno) | 0 € | 0 € | RT-4, M8. Vedi §5.2 se il volume supera il limite |
 | Monitoraggio errori | Sentry Developer | 0 € | 0 € | Come in sviluppo |
 **Totale produzione, costi certi: 172,65 €** + IPv4
 (ipotesi: produzione attiva per 12 mesi. Il numero reale di mesi dipende da quando decorre il primo anno: vedi §7.3, Q23)
 ### 5.2 Costi che dipendono dalle risposte del cliente
 | Voce | Da cosa dipende | Riferimento di prezzo | Stima annua | Note |
 |---|---|---|---|---|
 | **Firma elettronica** (RT-5) | ⏳ **Q4** tipo di firma e numero di firme l'anno | Confirmo API: **da 30 €/mese**, con costo aggiuntivo per ogni firma oltre la soglia · Youtrust API Plus: **104 €/mese** (1.248 €/anno), 500 firme semplici l'anno incluse, **2 € a firma** in più | **360 – 1.248 €** e oltre | Per la firma avanzata o qualificata i costi salgono (Youtrust: firma qualificata da 10 € l'una a pacchetti). Serve un preventivo del fornitore basato sui volumi |
 | **Marche temporali** (RT-6) | Numero di documenti archiviati l'anno (W4, passo 5), cioè numero di enti (Q1) × eventi | Aruba: **19,90 € per 100 marche** (0,20 € a marca) | Volume × 0,20 € | Esempio con ipotesi dichiarata: 500 documenti/anno = 5 pacchetti = **99,50 €**. Il volume reale va stimato con il cliente |
 | **Conservazione a norma** (RT-6) | ⏳ **Q9**: serve o no | Aruba DocFly: **49,90 €/anno** (1 GB) + **25 €/GB/anno** in più | Da 49,90 € | ⚠️ Il servizio è "uno per partita IVA": se la conservazione va fatta **a nome di ogni ente**, il costo si moltiplica per il numero di enti (Q1). ⚖️ Verifica C6 |
 | **Fatturazione elettronica** | ⏳ **Q5**: solo proforma o anche fattura elettronica | Non quotata | — | Se serve, si valuta l'integrazione con un servizio esistente invece di svilupparla |
 | **Email oltre il piano gratuito** | Volume: numero di enti (Q1) × alert e circolari | Brevo Starter: **da $8,08/mese** con pagamento annuale | Circa **$97/anno** | Serve solo se si superano 300 email al giorno. Con pochi enti è improbabile |
 | **Monitoraggio con più utenti** | Più persone da avvisare sugli errori | Sentry Team: **$26/mese** | **$312/anno** | Serve solo se lavora più di una persona sul software |
 ---
 ## 6. Scenari di spesa annua
 Tutti gli importi sono IVA esclusa. Ogni scenario dichiara le sue ipotesi.
 | Voce | Scenario minimo | Scenario alto |
 |---|---|---|
-| Costi certi (§3, §4, §5.1) | 1.318,53 € | 1.318,53 € |
+| Spese certe | 1.330,53 € | 1.330,53 € |
-| Firma elettronica | 360,00 € (firma semplice, piano base) | 1.248,00 € (piano con API e 500 firme incluse) |
+| Firma | 360,00 € (Confirmo base; firme incluse da verificare) | 1.248,00 € (F ≤ 500) |
-| Marche temporali | 19,90 € (100 marche) | 99,50 € (500 marche) |
+| Marche temporali | 16,00 € (M ≤ 100) | 70,00 € (M ≤ 500) |
-| Conservazione a norma | 0 € (Q9: non serve) | 99,90 € (1 archivio, 3 GB) |
+| Conservazione | 0 € | 99,90 € (A = 1, G = 3) |
-| Email | 0 € (piano gratuito) | ~$97 |
+| Email | 0 € | 85,03 € |
-| Monitoraggio | 0 € (piano gratuito) | $312 |
+| Monitoraggio | 0 € | 399,89 € |
-| **Totale** | **1.698,43 €** | **2.765,93 € + ~$409** |
+| **Totale** | **1.706,53 €** | **3.233,35 €** |
-**Lo scenario alto non è un massimo.** Non include:
+**L'alto non è un massimo.** Non include F > 500, firme qualificate o avanzate, l'abbonamento di firma attivato prima del rilascio, la conservazione per ogni ente o con API, la fatturazione elettronica e lo spazio disco aggiuntivo. Ognuna di queste voci si calcola con le formule del §4.
 - firme avanzate o qualificate pagate a firma;
 - la conservazione a nome di ogni ente;
 - la fatturazione elettronica;
 - l'IPv4.
-Se Q4, Q9 e Q1 vanno nella direzione più costosa, la spesa può superare lo scenario alto. Va rifatto il calcolo con le risposte del cliente.
+### 5.2 Esempi per numero di enti (usati nel documento per il cliente)
---
+🔸 Ipotesi: firma semplice; F = 3 × E; M = 4 × E; monitoraggio gratuito.
-## 7. Chi paga e quando
+| Voce | 30 enti | 200 enti |
 ### 7.1 Decisioni ✅
 | Decisione (`richiesta.md` §7) | Effetto sui costi |
 |---|---|
 | D10: primo anno a carico e a nome di Davide | Tutte le voci di questo documento (§3, §4, §5) vanno **nel preventivo di Davide** |
 | D11: dal secondo anno servizi al cliente, manutenzione a Davide | I costi del §5 passano al cliente; il compenso per la manutenzione si definisce nel contratto (tariffe decise da Davide) |
 ### 7.2 Conseguenze da mettere nel preventivo e nel contratto
 1. **Il passaggio dei servizi al cliente è un'attività di lavoro.** A fine primo anno vanno trasferiti account, dominio, backup, contratti con i fornitori, accessi, e va consegnato un documento con configurazioni e procedure (RT-15). Sono **ore di lavoro**, da stimare e mettere nel preventivo o nel contratto di manutenzione.
 2. **I fornitori devono essere trasferibili (RT-15).** In fase di architettura si scelgono servizi che permettono di passare account o contratti a un altro intestatario senza fermare il sistema. Un fornitore che non lo permette obbliga a una migrazione, che costa di più e può comportare un fermo del servizio.
 3. **Il rischio sui prezzi è di Davide.** Nel primo anno, se un fornitore aumenta i prezzi (Hetzner li ha aumentati a giugno 2026) o i volumi superano le stime (firme, marche, email), la differenza la paga Davide. Si può gestire in due modi, anche insieme:
   - una clausola nel contratto che lega le voci ai prezzi di listino a una data e prevede l'adeguamento oltre una soglia di volume;
   - un margine sulle voci variabili, deciso da Davide.
   ⚖️ Verifica C9.
 4. **Conservazione e firma avanzata potrebbero dover essere a nome del cliente fin dall'inizio** (⚖️ verifica C5): il costo del primo anno resta comunque a carico di Davide.
 5. **Rendicontazione:** i costi pagati da Davide entrano nel preventivo come voci di spesa; ammissibilità e forma da verificare (⚖️ C7).
 ### 7.3 Da quando decorre il primo anno? ⏳ Q23
 Il calcolo del §5 suppone 12 mesi di produzione. Il numero di mesi da mettere nel preventivo dipende però da quando decorre il primo anno:
 | Se il primo anno decorre… | Mesi di produzione a carico di Davide | Effetto |
 |---|---|---|
-| dalla **firma del contratto** | 12 meno i mesi di sviluppo prima del rilascio | Costo di produzione più basso; il passaggio avviene 12 mesi dopo la firma |
+| Spese certe | 1.330,53 € | 1.330,53 € |
-| dalla **messa in produzione** | 12 pieni, dopo il rilascio | Costo di produzione pieno; il periodo coperto da Davide dura più di 12 mesi, perché ai mesi di sviluppo si aggiungono 12 mesi di produzione. Anche gli strumenti di sviluppo (§3) e il test (§4) andrebbero calcolati su questo periodo più lungo |
+| Firma | F = 90 → 1.248,00 € | F = 600 → 1.448,00 € |
 | Marche | M = 120 → 22,00 € | M = 800 → 118,00 € |
 | Conservazione | non serve → 0 € | A = 1, G = 3 → 99,90 € |
 | Email | gratuito → 0 € | Starter → 85,03 € |
 | Disco | 0 € | D = 20 → 13,73 € |
 | **Totale** | **2.600,53 €** | **3.095,19 €** |
-La differenza tocca soprattutto Claude Max (90 €/mese), che è la voce più pesante. → Domanda **Q23**.
+Con 200 enti e conservazione a nome di ogni ente (A = 200), la conservazione sale a 9.980 € e il totale a **12.975,29 €**. È la voce più rischiosa: la verifica C6 va chiusa prima del preventivo.
 ---
-## 8. Fuori perimetro (da valutare a parte)
+## 6. Chi paga e cosa comporta
-Non sono costi del software, ma di Davide come professionista. Conviene valutarli con il commercialista, anche perché alcuni potrebbero essere ammissibili nel bando:
+### 6.1 Decisioni
- **assicurazione RC professionale e cyber:** il software tratta dati personali e antiriciclaggio, quindi un errore può avere conseguenze economiche;
+- **D10:** tutte le voci del §3 e del §4 vanno nel preventivo di Davide.
- **PEC** e **firma digitale** personali, per firmare contratti e offerte;
+- **D11:** dal secondo anno i costi di produzione passano al cliente; la manutenzione si definisce nel contratto.
- **password manager** per custodire in sicurezza gli accessi ai servizi di produzione;
+
- **hardware** di sviluppo.
+### 6.2 Conseguenze per preventivo e contratto
 1. **Il passaggio dei servizi al cliente è lavoro:** trasferire account, dominio, backup, contratti e accessi, e consegnare configurazioni e procedure (RT-15). Le ore sono da stimare (B1.9).
 2. **Fornitori trasferibili (RT-15):** per Hetzner è verificato che le risorse si spostano su un altro account con un progetto condiviso ([Hetzner](https://docs.hetzner.com/cloud/general/faq/)). Per gli altri fornitori va verificato alla scelta.
 3. **Il rischio sui prezzi nel primo anno è di Davide:** aumenti di listino (Hetzner li ha aumentati a giugno 2026) o volumi oltre le stime. Si gestisce con una clausola di adeguamento, con un margine sulle voci variabili, o con entrambi. ⚖️ C9.
 4. **Conservazione e firma avanzata potrebbero dover essere a nome del cliente fin dall'inizio** (⚖️ C5); il costo del primo anno resta a Davide.
 5. **Rendicontazione nel bando:** ⚖️ C7.
 ### 6.3 Da quando parte il primo anno (⏳ Q23)
 | Se parte… | Mesi di produzione a carico di Davide | Effetto |
 |---|---|---|
 | dalla firma del contratto | 12 meno i mesi di sviluppo | Produzione più breve; il passaggio avviene 12 mesi dopo la firma |
 | dalla messa in produzione | 12 pieni | Periodo totale più lungo di 12 mesi: si allungano anche sviluppo e test, e Claude Max è la voce che pesa di più |
 ### 6.4 I servizi previsti bastano?
 | Serve a | Servizio | Basta? |
 |---|---|---|
 | Server UE per applicazione e database (RT-13, RT-16) | Hetzner | ✅ |
 | Email: alert, proforma, circolari, recupero password (RT-4) | Brevo | ✅ |
 | Firma via API (RT-5, W1, W4) | Youtrust / Confirmo | ✅ con riserva: Q4; SMS con codice incluso da confermare |
 | Marca temporale automatica (RT-6, W4 passo 5) | Lotti via API | ✅ |
 | Conservazione a norma (RT-6, se Q9 = sì) | DocFly | ⚠️ Solo caricamento manuale: scegliere tra processo manuale (da scrivere in W4) e conservatore con API |
 | Dati nell'UE e contratti sul trattamento (RT-10) | Hetzner, Brevo, Sentry UE, Openapi (solo impronte) | ✅ Contratti da firmare con ciascuno (C1) |
 | Fattura elettronica (Q5) | — | ⏳ Solo se Q5 = sì |
 **Coperto con strumenti open source** (0 €, ma ore di configurazione):
 - generazione di PDF e Word (RT-7);
 - importazione di Excel e PDF (RT-8), con riconoscimento del testo se Q10 lo richiede;
 - scadenze e solleciti (W5);
 - antivirus sui file caricati dagli enti;
 - intercettazione delle email in test, così nessun messaggio arriva a persone reali;
 - seconda verifica all'accesso con codici da app (TOTP), senza SMS a pagamento.
 ---
-## 9. Domande che cambiano i costi
+## 7. Fuori perimetro
-| Codice | Effetto sui costi |
+Costi di Davide come professionista, da valutare con il commercialista (alcuni potrebbero essere ammissibili nel bando):
-|---|---|
+- assicurazione RC professionale e cyber (C11);
-| Q1 numero di enti | Volume di marche temporali, email, spazio; possibile moltiplicazione della conservazione |
+- PEC e firma digitale personali;
-| Q2 ripartizione degli utenti | Dimensionamento del server |
+- password manager per custodire e poi consegnare gli accessi (RT-15);
-| Q4 tipo di firma | Voce più incerta: da 360 € a oltre 1.200 €/anno |
+- hardware di sviluppo.
 | Q5 fatturazione elettronica | Possibile servizio aggiuntivo |
 | Q9 conservazione a norma | Da 0 € a 49,90 €/anno per archivio, per ogni ente se necessario |
 | Q23 ⏳ decorrenza del primo anno | Mesi di produzione e di strumenti da includere nel preventivo (§7.3) |
 ---
 ## 10. Fonti dei prezzi
 Prezzi consultati il 27/09/2026. Sono listini pubblici e **possono cambiare**: vanno riverificati prima di inviare il preventivo.
 | Voce | Fonte |
 |---|---|
 | Claude Max | [claude.com/pricing](https://claude.com/pricing) (da $100/mese); importo di 90 €/mese indicato da Davide |
 | Server Hetzner (CX23, CX33) | [Hetzner, adeguamento prezzi del 15/06/2026](https://docs.hetzner.com/general/infrastructure-and-availability/price-adjustment/) · [CostGoat, calcolatore Hetzner](https://costgoat.com/pricing/hetzner) |
 | Backup Hetzner (20%) e IPv4 | [Hetzner Docs, FAQ fatturazione](https://docs.hetzner.com/cloud/billing/faq/) |
 | Storage Box BX11 | [whtop.com, BX11](https://www.whtop.com/plans/hetzner.com/128269) (fonte terza) · [Hetzner, BX11](https://www.hetzner.com/storage/storage-box/bx11/) |
 | Dominio .it | [Aruba, listino domini](https://www.aruba.it/listino-domini.aspx) |
 | Email Brevo | [Brevo, prezzi](https://www.brevo.com/pricing/) · [SMTPedia, prezzi Brevo 2026](https://smtpedia.com/brevo-pricing/) |
 | Monitoraggio Sentry | [CostBench, prezzi Sentry 2026](https://costbench.com/software/developer-tools/sentry/) |
 | Firma elettronica | [Confirmo, prezzi API](https://www.confirmo.it/prezzi-firma-elettronica-api-confirmo) · [Youtrust (Yousign), prezzi API](https://youtrust.com/pricing-api) · [Youtrust, piani](https://youtrust.com/pricing-application) |
 | Marche temporali | [Ufficio Camerale, 100 marche Aruba](https://www.ufficiocamerale.it/marche-temporali/100-marche-temporali-aruba) |
 | Conservazione a norma | [Aruba PEC, DocFly](https://www.pec.it/docfly-conservazione-digitale-a-norma.aspx) |
 ---
@@ -208,17 +209,22 @@ Prezzi consultati il 27/09/2026. Sono listini pubblici e **possono cambiare**: v
 | Versione | Data | Allineato a | Modifiche |
 |---|---|---|---|
-| 0.2 | 27/09/2026 | `richiesta.md` v0.2 | Prima stesura: costi ricorrenti di sviluppo, test e produzione per 12 mesi, con prezzi di listino e scenari |
+| 0.2 | 27/09/2026 | `richiesta.md` v0.2 | Prima stesura |
-| 0.3 | 27/09/2026 | `richiesta.md` v0.3 | Registrate D10 e D11 (chi paga nel primo anno e dopo); riscritto il §7 con le conseguenze su preventivo e contratto; aggiunta Q23 (decorrenza del primo anno); aggiornato il §9 |
+| 0.3 | 27/09/2026 | `richiesta.md` v0.3 | D10 e D11: chi paga; aggiunta Q23 |
-| 0.3.1 | 27/09/2026 | `richiesta.md` v0.3 | Riorganizzazione senza modifiche ai costi: testo delle decisioni D10 e D11 e delle verifiche legali sostituito dal rimando a `richiesta.md` §7 e a `domande-cliente.md` parte C; tolte dal §9 le domande già chiuse |
+| 0.3.1 | 27/09/2026 | `richiesta.md` v0.3 | Rimandi a `richiesta.md` e `domande-cliente.md` al posto del testo ripetuto |
 | 0.4 | 27/09/2026 | `richiesta.md` v0.4 | PostgreSQL (D12) sul server di produzione, senza licenze |
 | 0.4.1 | 27/09/2026 | `richiesta.md` v0.4 | Rimandi aggiornati alla nuova numerazione di `domande-cliente.md` |
 | 0.4.2 | 27/09/2026 | `richiesta.md` v0.4 | Prezzi ricontrollati; IPv4; marche via API; monitoraggio della disponibilità; spazio disco; verifica della copertura dei servizi |
 | 0.4.3 | 27/09/2026 | `richiesta.md` v0.4 | Solo euro (cambio BCE del 25/09/2026); voci variabili come formule; esempi per 30 e 200 enti |
 | 0.4.4 | 27/09/2026 | `richiesta.md` v0.4 | Firma in test verificata: sandbox gratuita solo 40 giorni, quindi firma simulata durante lo sviluppo. Documento riscritto in forma lineare: link della fonte accanto a ogni prezzo (tolta la tabella separata delle fonti); costi fissi di tutti gli ambienti in una tabella; tolte le ripetizioni (domande che cambiano i costi, differenze rispetto alla v0.4.1, dettagli ripetuti tra sezioni). Nessuna cifra cambiata |
 | 0.4.5 | 27/09/2026 | `richiesta.md` v0.4 | §3 rinominato "Spese certe"; §4 riorganizzato in 4.1 "Legate a un requisito, importo aperto in attesa del cliente" (firma, marche, conservazione, fatturazione elettronica) e 4.2 "Facoltative, scelta indipendente dal cliente" (email, disco, monitoraggio). Numeri di sezione (§3, §4, §6.2) e cifre invariati: riferimenti da `architettura.md` e `blueprint.md` restano validi |
 ---
 ## Stato
- **Fase corrente:** analisi dei requisiti, costi ricorrenti v0.3.1.
+- **Fase corrente:** analisi dei requisiti, costi v0.4.5.
- **Decisioni prese:** D10 (primo anno a carico e a nome di Davide), D11 (dal secondo anno al cliente, manutenzione a Davide). Costi certi 1.318,53 € + IVA su 12 mesi; scenari tra 1.698,43 € e oltre 2.765,93 € + IVA.
+- **Decisioni prese:** D10, D11; firma simulata durante lo sviluppo, sandbox del fornitore solo negli ultimi 40 giorni.
 - **Prossimo passo:**
-  - chiarire con il cliente da quando decorre il primo anno (Q23);
+  - risposte del cliente a Q1, Q4, Q9 e Q23, poi ricalcolo con le formule del §4;
-  - verifiche C5, C6, C7, C9 (`domande-cliente.md` parte C);
+  - preventivo Confirmo (firme incluse, ambiente di prova); chiedere a Youtrust se il piano si paga mese per mese; chiedere a Openapi costi di servizio e validità dei lotti;
-  - stimare le ore del passaggio dei servizi a fine anno;
+  - verifiche C5, C6, C7, C9.
  - con le risposte a Q1, Q4 e Q9, ricalcolare gli scenari.
@@ -1,163 +1,101 @@
-# Domande per il cliente e dubbi architetturali
+# Domande per il cliente
 **Progetto:** Gestionale per enti del Terzo Settore
 **Documento:** `domande-cliente.md`
-**Versione:** 0.3.1 · **Data:** 27/09/2026 · **Stato:** Bozza
+**Versione:** 0.4.7 · **Data:** 27/09/2026 · **Stato:** Bozza
-**Allineato a:** `richiesta.md` v0.3 · **Schema di versione:** vedi `indice-documenti.md`
+**Allineato a:** `richiesta.md` v0.4 · **Schema di versione:** vedi `indice-documenti.md`
-**Cosa contiene:** tutto ciò che è ancora aperto. I codici (Q, RF, RT, D, M, W) rimandano a `richiesta.md` e `workflow.md`.
+Al cliente arrivano la sezione 1.1 e la sezione 2 con il documento `invii/2026-09-27_domande-cliente_v0.4.md` (`indice-documenti.md` §1.3). La sezione 3 è solo per Davide.
-| Parte | Contenuto | Si può inviare al cliente? |
+**Criterio:** restano solo le domande la cui risposta sposta molto costi od ore e che può dare solo il cliente, più le conferme dove le due fonti del cliente non concordano. Le altre sono ipotesi 🔸 (`richiesta.md` §7).
 |---|---|---|
 | **A** | Domande per il cliente, conferme sui processi, cose da comunicare | **Sì** |
 | **B** | Dubbi architetturali, scelte orientate, rischi, contesto delle domande | **No**, uso interno |
 | **C** | Verifiche con legale e commercialista | **No**, uso interno |
 ---
-# Parte A: per il cliente
+## 1. Domande
-## A1. Priorità alta: senza queste risposte non si può fare la stima
+### 1.1 Nel documento per il cliente
-| # | Domanda | Perché serve | Risposta |
+Colonna "N.": numero della domanda in `invii/2026-09-27_domande-cliente_v0.4.md`.
 | # | N. | Domanda | Risposta |
 |---|---|---|---|
-| Q1 | Quanti enti pensate di gestire con il software, oggi e tra 3 anni? | Dimensionamento della piattaforma e dei costi | |
+| Q1 | 1 | Quanti enti pensate di gestire, oggi e tra 3 anni? | |
-| Q2 | Sono previsti circa 100 utenti: quanti sono persone dello studio e quanti referenti degli enti? | Dimensionamento e permessi | |
+| Q4 | 2 | Che firma serve per offerte, privacy, antiriciclaggio e libri sociali: semplice (codice via SMS), avanzata o qualificata? | |
-| Q4 | Per accettare le offerte, la privacy e l'antiriciclaggio, e per i libri sociali, che firma serve? Una conferma semplice (click o codice via SMS), una firma elettronica avanzata o una firma digitale qualificata? | Scelta del fornitore di firma; è la voce di costo più incerta | |
+| Q9 | 3 | Per i libri sociali chiedete la conservazione digitale: basta un archivio nel software con data certa (marca temporale), o serve la conservazione a norma presso un conservatore accreditato? | |
-| Q5 | Il software deve emettere solo proforma o anche la fattura elettronica? Usate già un programma di fatturazione? | La fatturazione elettronica è un sotto-progetto a sé | |
+| Q5 | 4 | Il software deve fare anche la fattura elettronica, o bastano i proforma? Usate già un programma di fatturazione? | |
-| Q9 | Per i libri sociali basta un archivio con data certa (marca temporale), o serve la conservazione digitale a norma tramite un servizio esterno? Serve anche la stampa? | Fornitore esterno, costi ricorrenti, valore legale | |
+| Q10 | 5 | Gli estratti conto in PDF vanno letti in automatico o basta archiviarli? | |
-| Q10 | Gli estratti conto in PDF devono essere letti in automatico dal software, estraendo i movimenti, o basta archiviarli? Da quante banche diverse arrivano? | Rischio tecnico alto se si vuole la lettura automatica | |
+| Q13 | 6 | Chi prepara lo schema dei progetti per i bandi, e per quando? In che formato va esportato il progetto? L'adattamento ai formulari dei bandi lo fate voi a mano? | |
-| Q19 | Per progettazione e bilancio sociale, come lavorate con l'ente? (a) L'ente scrive e voi rivedete; (b) ognuno compila le sue parti; (c) lavorate sullo stesso documento, anche nello stesso momento. Vale lo stesso per entrambi? | Può cambiare di molto il costo di M6 e M7 | |
+| Q19 | 7 | In progettazione e bilancio sociale: (a) l'ente scrive e voi rivedete, (b) ognuno compila le sue parti, o (c) lavorate insieme sullo stesso documento? | |
-| Q23 | Il primo anno di servizi a mio carico parte dalla firma del contratto o dalla messa in produzione? In che data facciamo il passaggio dei servizi a voi? | Mesi di costi da inserire nel preventivo | |
+| Q26 | 8 | Le circolari sono previste nella prima fase, con la gestione del cliente (come nell'Excel). Nel Word sono tra le funzioni da aggiungere in un secondo momento: confermate che le volete subito? (conferma di D3) | |
 | Q25 | 9 | La qualifica dell'ente del Word (ODV, APS, ETS, impresa sociale, SOMS, rete, ente filantropico) e la sezione di iscrizione al RUNTS dell'Excel sono lo stesso dato? Se sì, prevediamo un solo campo (RF-2.7–2.8) | |
-## A2. Contenuto dei moduli
+### 1.2 Da trattare di persona o nel contratto
-| # | Domanda | Perché serve | Risposta |
+Non sono nel documento per il cliente: si chiudono all'incontro o si scrivono nel contratto.
 |---|---|---|---|
 | Q3 | Il catalogo dei servizi e dei pacchetti chi lo gestisce? Servono listini, sconti o aliquote IVA diverse? | Complessità di M1 | |
 | Q7 | Nella scheda dell'ente, numero soci e numero volontari si inseriscono a mano? | Coerenza con le anagrafiche | |
 | Q8.a | Quali tipi di persone deve gestire il software? Nei vostri documenti compaiono: soci, aderenti, tesserati, volontari, volontari occasionali, dipendenti/lavoratori, collaboratori, sostenitori, partecipanti. Aderenti e tesserati sono la stessa cosa? Sostenitori e partecipanti servono? | Modello dati di M3 | |
 | Q8.b | Oltre ad anagrafica e contatti, ci sono dati specifici da raccogliere per ogni tipo di persona? Per esempio la quota associativa per i soci, il tipo di contratto per i dipendenti | Modello dati di M3 | |
 | Q8.c | Una stessa persona può essere socio e volontario insieme? Il libro soci e il registro volontari devono prendere i dati da queste schede? | Struttura del database | |
 | Q12 | Le scadenze degli alert sono uguali per tutti gli enti ma modificabili: si modifica solo il calendario comune, o serve anche cambiare le scadenze di un singolo ente? | Complessità dello scadenziario | |
 | Q13 | Lo schema del progetto non c'è ancora: chi lo prepara (voi, o lo costruiamo insieme) e per quando? In che formato va esportato il progetto (Word, PDF)? L'adattamento ai formulari dei bandi lo fate a mano o deve farlo il software? | Senza schema M6 non è stimabile | |
 | Q14.a | Nell'Excel la descrizione del bilancio sociale è identica a quella della progettazione: è un errore? Il bilancio sociale deve seguire le linee guida ministeriali per gli ETS? | Correttezza dei requisiti di M7 | |
 | Q14.b | Le sezioni del bilancio sociale sono quelle di entrambi i documenti (con "lettera del presidente" e "serie di dati standard")? Cosa intendete per "serie di dati standard"? | Correttezza dei requisiti di M7 | |
 | Q15 | Chi stabilisce il valore di un'ora per ogni tipo di attività dei volontari? In che forma l'ente vi manda le ore (Excel, carta, email)? | Modello dati di M9 ed eventuale importazione | |
-## A3. Organizzazione del progetto
+| # | Domanda | Risposta |
 | # | Domanda | Perché serve | Risposta |
 |---|---|---|---|
 | Q18 | Chi approva i requisiti da parte vostra? Se durante lo sviluppo servono modifiche, come le gestiamo (richiesta scritta, stima, approvazione)? | Controllo dello scope creep | |
 | Q20 | Dove il Word e l'Excel elencano campi o sezioni diversi senza contraddirsi, confermate che vanno inclusi tutti? | Chiude le righe "Unione" tra i due documenti | |
 ## A4. Conferme sui processi
 Passi 🔸 che il workflow prevede ma le fonti non citano. Vanno confermati prima di considerarli requisiti.
 | Workflow | Domanda | Risposta |
 |---|---|---|
-| W1 | Un ente può rifiutare un'offerta? Un'offerta non firmata deve scadere dopo un certo tempo? | |
+| Q23 | Il primo anno di servizi a mio carico parte dalla firma del contratto o dalla messa in produzione? | |
-| W1 | È lo studio a creare l'accesso al software per il referente di ogni ente? | |
+| Q18 | Chi approva i requisiti da parte vostra? Se durante il lavoro volete cambiare qualcosa, vi va bene chiederlo per email, ricevere una stima e dare l'ok prima che proceda? | |
 | W2 | Lo studio registra nel software l'avvenuto pagamento? Come si gestiscono i ritardi? | |
 | W4 | Lo studio può rimandare un documento all'ente con osservazioni da correggere? | |
 | W5 | Se l'ente non carica i documenti alla scadenza, il software deve mandare solleciti e avvisare lo studio? | |
 | W5 | Lo studio controlla e approva Modello D e relazione illustrativa prima dell'esportazione? | |
 | W7 | Le circolari vanno sempre a tutti gli enti, o anche a gruppi (per esempio per qualifica)? | |
 ## A5. Da comunicare al cliente (non sono domande)
 | Punto | Cosa dire |
 |---|---|
 | Inserimento iniziale dei dati (D8) | Non è prevista l'importazione di dati esistenti: ogni ente inserirà a mano i soci e i volontari che ha già. Se è un problema, l'importazione da Excel si può quotare a parte |
 | Uso da smartphone (D9) | Il software è pensato per computer: da smartphone si apre, ma non viene progettato né collaudato per quell'uso |
 | Hosting | I dati saranno ospitati nell'Unione Europea, per rispettare il GDPR |
 | Servizi di produzione (D10, D11) | Il primo anno sono a mio nome e a mio carico; dal secondo anno passano a voi, con un contratto di manutenzione separato |
 | Materiali da consegnare | Servono da voi: schema del progetto, modelli di verbale e di circolare, un esempio di estratto conto per ogni banca, tariffe orarie del volontariato |
 **Domande già chiuse:** Q6 → D5 · Q11 → D6 · Q12 (in parte) → D7 · Q13 (in parte: lo schema non esiste, RF-6.5) · Q16 → D8 · Q17 → D9 · Q21 → D10 · Q22 → D11.
 ---
-# Parte B: dubbi architetturali (uso interno)
+## 2. Da comunicare al cliente
-## B1. Scelte che dipendono dalle risposte del cliente
+Sono nel documento per il cliente, §2:
-
+- decisioni da comunicare: D2 (RT-1), D8 (RT-14; importazione da Excel quotabile a parte), D9 (RT-12, RT-13), D10–D11;
-| # | Dubbio | Dipende da | Orientamento attuale |
+- ipotesi 🔸 da validare al collaudo (`richiesta.md` §7 e passi 🔸 di `workflow.md`), descritte in modo semplice;
-|---|---|---|---|
+- **materiali da chiedere al cliente, con una data di consegna:** schema del progetto, modelli di verbale e circolare, un estratto conto di esempio per banca, tariffe orarie del volontariato.
 | B1.1 | **Struttura dell'anagrafica persone:** una scheda per persona con più ruoli, o una scheda per ruolo? | Q8.c | Una scheda per persona con più ruoli: i dati si inseriscono una volta sola e alimentano libro soci e registro volontari. Va deciso prima di iniziare, perché definisce il database |
 | B1.2 | **Come stimare M6 e M7** se Q13 e Q19 restano senza risposta | Q13, Q19 | Stimare sull'opzione (a) di Q19 e scriverlo nel preventivo come assunzione; (b) e (c) come varianti quotate a parte |
 | B1.3 | **Estratti conto:** lettura automatica del PDF o solo archiviazione | Q10 | Fase 1: import da Excel/CSV e archiviazione del PDF. Lettura automatica solo come evoluzione: ogni banca ha un formato diverso e il risultato è poco affidabile |
 | B1.4 | **Fornitori esterni** per firma, marca temporale e conservazione | Q4, Q9 | Fornitori qualificati, non soluzioni fatte in casa. Si scelgono dopo le risposte |
 | B1.5 | **Fatturazione elettronica** | Q5 | Se serve, voce separata o integrazione con un software già in uso, non sviluppo da zero |
 | B1.6 | **Scadenziario degli alert:** solo calendario comune, o anche modifiche per singolo ente | Q12 | La seconda comprende la prima: se la risposta tarda, progettare il database già pronto per le modifiche per ente |
 | B1.7 | **Numero soci e volontari manuale** | Q7 | Se si conferma, mostrare accanto il conteggio calcolato dalle anagrafiche, come controllo |
 | B1.8 | **Fornitori trasferibili** (RT-15) | Q23 | Criterio obbligatorio per tutti i fornitori di produzione: verificare per ciascuno il cambio di intestatario senza migrazione |
 | B1.9 | **Ore del passaggio** dei servizi al cliente | Q23 | Stimarle e metterle nel preventivo o nel contratto di manutenzione: trasferimento di account e dominio, documento di consegna |
 ## B2. Scelte già orientate, da motivare nel preventivo
 | # | Scelta | Motivazione |
 |---|---|---|
 | B2.1 | Separazione rigorosa dei dati tra enti | Un ente non deve mai vedere i dati di un altro (RT-1): condiziona database, permessi e test di sicurezza |
 | B2.2 | Voci del Modello D in una tabella configurabile | L'imputazione usa le voci del Modello D (D6): se il Ministero cambia lo schema, si aggiorna la tabella senza toccare il codice |
 | B2.3 | Un solo sistema di notifiche (email + app) per alert, proforma e circolari | Serve comunque per gli alert (RT-4): il doppio canale delle circolari (D5) costa più di un canale solo ma non il doppio, e dà allo studio lo stato di lettura, che la sola email non garantisce |
 | B2.4 | Un solo flusso di approvazione riusato nei moduli | Serve per i libri sociali e probabilmente per M5–M7 (RT-3) |
 | B2.5 | Registro delle operazioni | Valore probatorio dei libri sociali e GDPR (RT-9) |
 ## B3. Rischi
 I rischi economici del primo anno (aumenti di prezzo, volumi, passaggio dei servizi) sono in `costi-ricorrenti.md` §7.2.
 | Rischio | Dove nasce | Come contenerlo |
 |---|---|---|
 | Scope creep su M6 | Schema del progetto inesistente (Q13), divisione del lavoro non definita (Q19) | Assunzione dichiarata nel preventivo (B1.2); schema consegnato prima dello sviluppo del modulo |
 | Scope creep su M7 | Descritto solo per titoli | Fase 2 stimata a parte, requisiti firmati prima dell'avvio |
 | Modifiche non controllate | Nessuna procedura (Q18) | Procedura scritta: richiesta, stima, approvazione |
 | Dipendenza dal cliente | Materiali da ricevere (A5) | Elenco dei materiali con date di consegna nel preventivo |
 | Richiesta di importazione a progetto avviato | Nessuna migrazione prevista (D8) | Dirlo subito (A5); import da Excel come voce opzionale |
 | Sicurezza e privacy | Molte persone, possibili dati art. 9, dati antiriciclaggio | Privacy by design, contratti sul trattamento dei dati, hosting UE, verifiche C1–C3 |
 | Valore legale dei documenti | Firma, marca temporale e conservazione hanno requisiti normativi | Fornitori qualificati (B1.4), verifica C4 |
 | Estratti conto PDF | Formati diversi per ogni banca | B1.3 |
 | Norme che cambiano | Modello D, bilancio sociale e RUNTS possono cambiare per legge | Voci e modelli configurabili (B2.2) |
 ## B4. Contesto delle domande
 Spiegazioni per chi conduce l'incontro. Non vanno inviate.
 **B4.1 Q8, le persone dell'ente.** Le fonti citano 9 categorie, non le stesse (`richiesta.md` M3); alcune potrebbero coincidere ("aderenti" e "tesserati", "dipendenti" e "lavoratori"). Alcune categorie potrebbero avere dati propri (quota associativa, tipo di contratto, data di assunzione). Sulla possibilità di più ruoli per persona, le strade sono due:
 - **una scheda per persona, con più ruoli**: dati inseriti e aggiornati in un solo punto; va decisa subito perché definisce il database;
 - **una scheda per ruolo**: più semplice all'inizio, ma la stessa persona compare più volte, con il rischio di dati diversi.
 **B4.2 Q14, il bilancio sociale.** Nell'Excel la colonna "Funzioni" della Rendicontazione sociale dice *"Guidare gli utenti nella stesura di un progetto secondo un modello standard facilmente convertibile sui formulari imposti dagli enti erogatori"*: è la stessa frase della Progettazione. Per il bilancio sociale non ha senso, perché non è un progetto per un bando. Il bilancio sociale degli ETS segue le linee guida ministeriali (DM 4 luglio 2019). Quasi sicuramente è un copia-incolla. Le sezioni differiscono per "serie di dati standard" [D] e "lettera del presidente" [X].
 **B4.3 Q19, divisione del lavoro in M6 e M7.** Le fonti dicono solo che ci lavorano ente e studio ("entrambi" in [X], "l'operatore" in [D]). Le opzioni hanno costi molto diversi:
 | Opzione | Come funziona | Impatto sullo sviluppo |
 |---|---|---|
 | (a) Redazione e revisione | L'ente scrive, lo studio rivede e approva, come per i libri sociali | Il più semplice: riusa il flusso di approvazione (RT-3) |
 | (b) Sezioni divise | Alcune sezioni le compila l'ente, altre lo studio (es. piano economico-finanziario) | Medio: permessi per singola sezione |
 | (c) Modifica contemporanea | Ente e studio lavorano sullo stesso documento nello stesso momento | Il più costoso: gestione dei conflitti e aggiornamento in tempo reale |
 La risposta può essere diversa per M6 e M7. Il workflow (W6, W8) è scritto sull'opzione (a).
 ---
-# Parte C: verifiche con legale e commercialista (uso interno) ⚖️
+## 3. Per Davide (non inviare)
-| # | Da verificare | Con chi | Collegato a |
+### Verifiche ⚖️, in ordine di urgenza
 **Commercialista**
 - **C12** Il bando pone vincoli su budget complessivo e date di consegna? *(prima dell'incontro)*
 - **C7** Claude Max e servizi pagati da me sono ammissibili nel bando? In che forma?
 - **C8** IVA sui servizi esteri (reverse charge).
 - **C9** Clausola per aumenti di prezzo o volumi oltre stima nel primo anno.
 **Legale**
 - **C6** La conservazione a norma va fatta a nome di ogni ente? (può moltiplicare i costi)
 - **C5** Conservazione e firma avanzata possono essere a mio nome nel primo anno?
 - **C1** Ruoli privacy e contratti sul trattamento dei dati.
 - **C13** Serve la valutazione d'impatto (art. 35 GDPR)? Se sì, prima dello sviluppo.
 - **C2** Misure per i possibili dati particolari (art. 9 GDPR).
 - **C4** Valore legale di firma, marca temporale e conservazione dei libri sociali.
 - **C3** Tempi e misure di conservazione dei dati antiriciclaggio.
 - **C11** Mie responsabilità come intestatario dei servizi (assicurazione RC e cyber).
 - **C10** Contratto di manutenzione dal secondo anno.
 ### Scelte in sospeso
 | # | Scelta | Dipende da | Orientamento |
 |---|---|---|---|
-| C1 | **Ruoli privacy:** studio titolare per i propri clienti e responsabile per i dati degli enti; sviluppatore e hosting sub-responsabili; contratti sul trattamento dei dati conseguenti | Legale | `richiesta.md` §5 |
+| B1.2 | Stima di progettazione e bilancio sociale senza risposte | Q13, Q19 | Stimare sull'opzione (a) di Q19, dichiarandolo; (b) e (c) come varianti |
-| C2 | **Dati particolari (art. 9 GDPR):** l'iscrizione ad alcuni enti può rivelarli; quali misure di sicurezza aggiuntive servono | Legale | M3 |
+| B1.3 | Estratti conto PDF | Q10 | Prima solo import Excel/CSV e archivio del PDF |
-| C3 | **Antiriciclaggio:** per quanto tempo conservare i dati e con quali misure | Legale / commercialista | RF-1.6 |
+| B1.4 | Fornitori di firma, marca, conservazione | Q4, Q9 | Fornitori qualificati |
-| C4 | **Valore legale** di firma, marca temporale e conservazione digitale dei libri sociali degli ETS | Legale | RT-5, RT-6 |
+| B1.5 | Fattura elettronica | Q5 | Integrazione, non sviluppo da zero |
-| C5 | **Intestazione nel primo anno:** conservazione a norma e firma elettronica avanzata possono essere a nome di Davide per conto dello studio, o devono essere a nome del cliente fin dall'inizio (con costi comunque a carico di Davide)? | Legale | D10 |
+| B1.9 | Ore per il passaggio dei servizi | Q23 | Da stimare nel preventivo |
-| C6 | **Conservazione per ente:** il servizio di riferimento è "uno per partita IVA"; la conservazione va fatta a nome di ogni ente? Molti enti hanno solo il codice fiscale | Legale / fornitore | RT-6, costi §5.2 |
+| B1.10 | Linguaggio e framework dell'applicazione | Conoscenza di Davide; RT-15 | Orientato su Django (Davide conosce Python), non ancora deciso: `architettura.md` §6 |
-| C7 | **Rendicontazione del bando:** ammissibilità degli strumenti di sviluppo (Claude Max) e dei servizi di produzione pagati da Davide; forma (servizio di hosting o rimborso di abbonamenti) | Commercialista | D10, costi §7.2 |
+| B1.11 | Guida d'uso e formazione degli utenti | — | Nessun requisito nelle fonti; se offerte, vanno nel preventivo (`blueprint.md` §6) |
-| C8 | **IVA sui servizi esteri** (reverse charge) | Commercialista | Costi §1 |
+| B1.12 | Correzione dei difetti nel primo anno (garanzia) | ⚖️ C10 | Da distinguere dalla manutenzione del secondo anno (D11), nel preventivo o nel contratto |
-| C9 | **Clausola sui prezzi:** adeguamento se nel primo anno i fornitori aumentano i prezzi o i volumi superano le stime | Commercialista / legale | Costi §7.2 |
+
-| C10 | **Contratto di manutenzione:** contenuto, durata, responsabilità di Davide dal secondo anno | Legale | D11 |
+**Già orientate (motivate in `architettura.md`, da riportare nel preventivo):** B2.1 dati separati per ente (RT-1) · B2.2 voci del Modello D configurabili (D6) · B2.3 un solo sistema di notifiche email + app (RT-4) · B2.4 un solo flusso di approvazione (RT-3) · B2.5 registro delle operazioni (RT-9) · B2.6 un'unica applicazione con pagine generate dal server (§2) · B2.7 un server per ambiente, con applicazione e database in container (§8).
-| C11 | **Responsabilità come intestatario dei servizi nel primo anno:** contratti con i fornitori, misure di sicurezza, assicurazione RC professionale e cyber | Legale | D10 |
+
 ### Da chiedere più avanti
 Q14 (sezioni del bilancio sociale) e Q15 (valore delle ore di volontariato): prima di sviluppare la fase 2.
 ### Rischi principali
 - **Stima sbagliata su requisiti vaghi** (soprattutto progettazione): assunzioni dichiarate nel preventivo (B1.2).
 - **Modifiche non controllate:** procedura concordata (Q18).
 - **Materiali del cliente in ritardo:** date di consegna nel contratto.
 - **Privacy e sicurezza:** verifiche C1, C2, C13; hosting UE.
 - Rischi economici del primo anno: `costi-ricorrenti.md` §6.2.
 - Rischi di pianificazione (schema dei progetti, date del bando, sandbox di firma di 40 giorni): `blueprint.md` §5.
 **Già chiuse:** Q6 → D5 · Q11 → D6 · Q12 → D7 · Q16 → D8 · Q17 → D9 · Q20 → D13 · Q21 → D10 · Q22 → D11. Sostituite da ipotesi 🔸 in `richiesta.md`: Q2, Q3, Q7, Q8 e le conferme sui processi. B1.1, B1.6 e B1.7 sono ora ipotesi in `richiesta.md` (RF-3.3, RF-5.1, RF-2.13–2.14). B1.8 (fornitori trasferibili) è il requisito RT-15.
 ---
@@ -165,13 +103,24 @@ La risposta può essere diversa per M6 e M7. Il workflow (W6, W8) è scritto sul
 | Versione | Data | Allineato a | Modifiche |
 |---|---|---|---|
-| 0.2 | 25/09/2026 | `richiesta.md` v0.2 | Prima stesura (numerata inizialmente 1.0, riportata a 0.2) |
+| 0.2 | 25/09/2026 | `richiesta.md` v0.2 | Prima stesura |
-| 0.3 | 27/09/2026 | `richiesta.md` v0.3 | Aggiunti Q23, B1.8, B1.9, verifiche e rischi conseguenti a D10 e D11 |
+| 0.3 | 27/09/2026 | `richiesta.md` v0.3 | Aggiunti Q23, B1.8, B1.9 e verifiche su D10 e D11 |
-| 0.3.1 | 27/09/2026 | `richiesta.md` v0.3 | Riorganizzazione: diventa il documento unico di tutto ciò che è aperto. Aggiunta colonna "Perché serve"; Q23 spostata in A1; aggiunta A4 con i passi da confermare del workflow (prima in `workflow.md` §12); aggiunte in A5 le condizioni sui servizi di produzione; rischi riuniti in B3 (prima anche in `richiesta.md` §10); spiegazioni di Q8, Q14, Q19 in B4 (prima in `richiesta.md` §3.3 e §8); verifiche legali riunite nella parte C (prima in B3, in `richiesta.md` §5 e in `costi-ricorrenti.md` §7.2) |
+| 0.3.1 | 27/09/2026 | `richiesta.md` v0.3 | Riuniti qui tutti i punti aperti |
 | 0.3.2 | 27/09/2026 | `richiesta.md` v0.3 | Aggiunti Q24, C12, C13; ordinato per priorità |
 | 0.3.3 | 27/09/2026 | `richiesta.md` v0.3 | Semplificato: una riga per verifica e per scelta |
 | 0.3.4 | 27/09/2026 | `richiesta.md` v0.3 | Tolta la proposta di prima versione (Q24); domande in un'unica tabella |
 | 0.4 | 27/09/2026 | `richiesta.md` v0.4 | Ridotte a 9 domande essenziali. Q2, Q3, Q7, Q8 e conferme sui processi sostituite da ipotesi 🔸 in `richiesta.md`; Q20 chiusa da D13; Q14 e Q15 rimandate alla fase 2; Q18 riformulata in modo più chiaro |
 | 0.4.1 | 27/09/2026 | `richiesta.md` v0.4 | Allineamento: Q19 riporta le tre opzioni (a), (b), (c) citate da `workflow.md` (W6, W8) e da B1.2 |
 | 0.4.2 | 27/09/2026 | `richiesta.md` v0.4 | Allineamento: Q13 torna a chiedere formato di esportazione e adattamento ai formulari (servono a RF-6.3 e W6); Q5 torna a chiedere se esiste un programma di fatturazione (serve a B1.5); tolto dalla sezione 2 il riferimento a un file interno |
 | 0.4.4 | 27/09/2026 | `richiesta.md` v0.4 | Tolte le ripetizioni: §2 rimanda alle decisioni invece di riscriverle (resta qui solo l'elenco dei materiali); corrispondenza con le domande della proposta spostata qui dall'indice (colonna "N."); B1.8 chiusa perché coincide con RT-15; rimando ai rischi economici aggiornato a `costi-ricorrenti.md` §6.2 |
 | 0.4.3 | 27/09/2026 | `richiesta.md` v0.4 | Allineato alla proposta: §1 diviso tra le 7 domande della proposta (1.1) e Q23, Q18 da trattare di persona o nel contratto (1.2); indicato che i punti del §2 sono nella proposta |
 | 0.4.5 | 27/09/2026 | `richiesta.md` v0.4 | Collegamento ai nuovi `architettura.md` e `blueprint.md`: aggiunte le scelte B1.10 (stack), B1.11 (guida d'uso e formazione), B1.12 (garanzia nel primo anno) e le scelte già orientate B2.6, B2.7; motivazioni delle B2 rimandate ad `architettura.md`; aggiunto il rimando ai rischi di pianificazione |
 | 0.4.6 | 27/09/2026 | `richiesta.md` v0.4 | La proposta CSV è sostituita dal documento `invii/2026-09-27_domande-cliente_v0.4.md` (domande e comunicazioni, senza il riepilogo delle funzioni). Aggiunte Q25 (qualifica e sezione RUNTS) e Q26 (conferma delle circolari in fase 1), nate dalla verifica sulle fonti; criterio esteso alle conferme sui punti in cui le fonti non concordano. Q9 precisa che la conservazione digitale è già richiesta da [D]. §2: aggiunta D2 e le ipotesi 🔸 da validare al collaudo |
 | 0.4.7 | 27/09/2026 | `richiesta.md` v0.4 | B1.10 orientata su Django (Davide conosce Python), non ancora decisione formale: `architettura.md` §6 |
 ---
 ## Stato
 - **Fase corrente:** analisi dei requisiti, domande pronte per il cliente.
- **Decisioni prese:** D1–D11 (`richiesta.md` §7).
+- **Decisioni prese:** D1–D13 (`richiesta.md` §7). B1.10 orientata su Django, non ancora decisione.
- **Prossimo passo:** incontro con il cliente sulla parte A, partendo da A1; in parallelo verifiche della parte C.
+- **Prossimo passo:** commercialista su C12; invio del documento delle domande (9 domande); Q23 e Q18 all'incontro o nel contratto; conferma di B1.10 come decisione formale.
@@ -25,13 +25,26 @@ Ogni informazione sta in **un solo documento**; gli altri la richiamano con il s
 | Documento | Contenuto (e solo questo) | Versione | Stato | Allineato a |
 |---|---|---|---|---|
-| `richiesta.md` | **Documento base.** Cosa deve fare il software: moduli, requisiti (RF, RT), dati personali, differenze tra le fonti, decisioni (D) | **0.3.1** | Bozza | Fonti del 25/09/2026 |
+| `richiesta.md` | **Documento base.** Cosa deve fare il software: moduli, requisiti (RF, RT), dati personali, differenze tra le fonti, decisioni (D) | **0.4.5** | Bozza | Fonti del 25/09/2026 |
-| `workflow.md` | Processi del software passo per passo (W), con i riferimenti ai requisiti | **0.3.1** | Bozza | `richiesta.md` v0.3 |
+| `workflow.md` | Processi del software passo per passo (W), con i riferimenti ai requisiti | **0.4.3** | Bozza | `richiesta.md` v0.4 |
-| `domande-cliente.md` | Tutto ciò che è aperto: domande per il cliente (Q), conferme sui processi, dubbi architetturali (B), rischi, verifiche con legale e commercialista (C) | **0.3.1** | Bozza | `richiesta.md` v0.3 |
+| `domande-cliente.md` | Tutto ciò che è aperto: domande essenziali per il cliente (Q), cose da comunicare, verifiche con legale e commercialista (C), scelte in sospeso (B), rischi | **0.4.7** | Bozza | `richiesta.md` v0.4 |
-| `costi-ricorrenti.md` | Costi ricorrenti di sviluppo, test e produzione: prezzi con fonte, scenari, effetti economici delle decisioni | **0.3.1** | Bozza | `richiesta.md` v0.3 |
+| `costi-ricorrenti.md` | Costi ricorrenti di sviluppo, test e produzione: prezzi con fonte, spese certe e da quantificare, scenari, effetti economici delle decisioni | **0.4.5** | Bozza | `richiesta.md` v0.4 |
 | `architettura.md` | Come si costruisce il software: forma dell'applicazione, componenti, dati, permessi, confronto sugli stack, sicurezza, infrastruttura e rilascio (uso interno) | **0.4.5** | Bozza | `richiesta.md` v0.4 |
 | `blueprint.md` | Come si organizza la realizzazione: prerequisiti, pacchetti di lavoro (P) con dipendenze, tappe di collaudo (T), rischi di pianificazione; base per la stima delle ore (uso interno) | **0.4.2** | Bozza | `richiesta.md` v0.4 |
 | `indice-documenti.md` | Versioni in vigore e schema di versione | — | — | — |
 | `CLAUDE.md` | Istruzioni per Claude: regole, convenzioni, procedura di aggiornamento | — | In uso | Non segue lo schema di versione |
 ### 1.3 Invii al cliente
 Copie fisse di ciò che viene preparato o inviato al cliente (cartella `invii/`). Non si modificano: se serve una versione nuova, si crea un nuovo file.
 | File | Contenuto | Basato su | Stato |
 |---|---|---|---|
 | `invii/2026-09-27_domande-cliente_v0.4.md` | Domande formali per il cliente: 9 domande (corrispondenza con i codici Q in `domande-cliente.md` §1.1), decisioni già prese, funzioni completate con ipotesi da verificare al collaudo, materiali da chiedere con data di consegna. Sostituisce la proposta CSV, mai inviata ed eliminata. Q23 e Q18 non incluse, da trattare di persona o nel contratto | `richiesta.md` v0.4.4, `workflow.md` v0.4.2, `domande-cliente.md` v0.4.6 (§1.1 e §2) | Preparato, non ancora inviato |
 | `invii/2026-09-27_costi_v0.4.md` | Costi del primo anno in versione semplice per datore di lavoro e cliente: costi fissi, costi variabili con la formula di calcolo, esempi di totale con 30 e 200 enti, chi paga. Solo euro; niente fonti, rischi o verifiche interne | `costi-ricorrenti.md` v0.4.3 | Preparato, non ancora inviato |
 **Simboli usati nei documenti:** ✅ deciso · ⏳ aperto, da chiedere al cliente · 🔸 ipotesi o passo dedotto, da confermare · ⚖️ da verificare con legale o commercialista.
 **Dipendenze:**
 ```
@@ -41,7 +54,10 @@ fonti/AAAA-MM-GG/ (docx, xlsx del cliente)
        ↓
   ├── workflow.md
   ├── domande-cliente.md
-   └── costi-ricorrenti.md
+   ├── costi-ricorrenti.md
   └── architettura.md
            ↓
       blueprint.md  (usa anche workflow, domande e costi)
 ```
 ---
@@ -57,15 +73,15 @@ fonti/AAAA-MM-GG/ (docx, xlsx del cliente)
 | **Z** | Correzione | Solo per correzioni che **non cambiano i requisiti**: refusi, riformulazioni, formattazione. Si omette quando è 0 (0.2 = 0.2.0) |
 **Esempi:**
- Il cliente risponde a Q1 → `richiesta.md` passa da 0.2 a **0.3**.
+- Il cliente risponde a Q1 → `richiesta.md` passa da 0.4 a **0.5**, e i documenti derivati si allineano a 0.5.
- Si corregge un refuso in `workflow.md` → `workflow.md` passa da 0.2 a **0.2.1**; gli altri documenti non cambiano.
+- Si corregge un refuso in `workflow.md` → `workflow.md` passa da 0.4 a **0.4.1**; gli altri documenti non cambiano.
 - Il cliente approva i requisiti → tutti i documenti passano a **1.0**.
 - Dopo l'approvazione il cliente chiede una modifica → `richiesta.md` passa a **1.1** (proposta), poi a **2.0** quando la modifica è approvata.
 ### 2.2 Regola di allineamento
 1. **`richiesta.md` è il documento base.** Ogni modifica ai requisiti parte da lì.
-2. I documenti derivati (workflow, domande, costi) **usano le stesse X e Y** della versione di `richiesta.md` a cui sono allineati. La Z è propria di ogni documento.
+2. I documenti derivati (workflow, domande, costi, architettura, blueprint) **usano le stesse X e Y** della versione di `richiesta.md` a cui sono allineati. La Z è propria di ogni documento.
 3. Un documento derivato con X.Y diversa da `richiesta.md` è **disallineato** e va aggiornato prima di essere usato o inviato.
 ### 2.3 Cosa si fa a ogni cambio di versione
@@ -78,8 +94,8 @@ fonti/AAAA-MM-GG/ (docx, xlsx del cliente)
 ### 2.4 Nomi dei file
-I nomi dei file **non contengono la versione** (`richiesta.md`, non `richiesta_v0.2.md`). Così i riferimenti tra documenti restano validi.
+I nomi dei file **non contengono la versione** (`richiesta.md`, non `richiesta_v0.4.md`). Così i riferimenti tra documenti restano validi.
-La versione si legge nell'intestazione e in questo indice. Quando un documento viene **inviato al cliente**, se ne conserva una copia con la versione nel nome (es. `invii/2026-09-25_domande-cliente_v0.2.md`), per sapere sempre cosa ha ricevuto il cliente.
+La versione si legge nell'intestazione e in questo indice. Quando un documento viene **inviato al cliente**, se ne conserva una copia con la versione nel nome (es. `invii/2026-09-27_domande-cliente_v0.4.md`; solo §1 e §2, mai il §3), per sapere sempre cosa ha ricevuto il cliente.
 ---
@@ -94,3 +110,24 @@ La versione si legge nell'intestazione e in questo indice. Quando un documento v
 | 27/09/2026 | Aggiunto `costi-ricorrenti.md` (v0.2) in §1.2 e nelle dipendenze; aggiunto il documento alla tabella di `CLAUDE.md` |
 | 27/09/2026 | Tutti i documenti di progetto portati a v0.3 per le decisioni D10 e D11 (chi paga e gestisce i servizi di produzione) |
 | 27/09/2026 | Riorganizzazione per eliminare le informazioni ripetute: eliminato `richiesta-sintesi.md` (ripeteva `richiesta.md`); `richiesta.md`, `workflow.md`, `domande-cliente.md` e `costi-ricorrenti.md` portati a v0.3.1; descritto in §1.2 il contenuto esclusivo di ogni documento; aggiornato `CLAUDE.md` (elenco documenti, codici Cn) |
 | 27/09/2026 | Tutti i documenti portati a v0.4 (D12 PostgreSQL con migrazioni, D13 priorità all'Excel, domande ridotte a 9); aggiornato `CLAUDE.md` (fase attuale e regola sul database) |
 | 27/09/2026 | Allineamento generale: `richiesta.md`, `domande-cliente.md` e `costi-ricorrenti.md` a v0.4.1 (Q19 con tre opzioni, rimandi alla nuova numerazione, nota sull'originale di [D]); aggiornati §1.2 ed esempi del §2; `CLAUDE.md` allineato alla nuova struttura di `domande-cliente.md` |
 | 27/09/2026 | Verifica completa di coerenza: `richiesta.md` e `domande-cliente.md` a v0.4.2 (motivazione di RT-13, contenuto di Q5 e Q13, nessun file interno nelle sezioni per il cliente) |
 | 27/09/2026 | Aggiunto §1.3 "Invii al cliente" con `invii/2026-09-27_proposta_v0.4.csv` |
 | 27/09/2026 | Proposta semplificata (stesse colonne dell'Excel del cliente); sostituisce la bozza precedente dello stesso file, mai inviata |
 | 27/09/2026 | Proposta sostituita con la versione rivista da Davide (note ridotte, senza indicazione delle fasi, domanda 9 vuota) |
 | 27/09/2026 | Proposta aggiornata da Davide: tolte le domande su decorrenza del primo anno (Q23) e approvazione/modifiche (Q18), che restano aperte in `domande-cliente.md` |
 | 27/09/2026 | Allineamento alla proposta: `domande-cliente.md` a v0.4.3; `CLAUDE.md` aggiornato (cartella `invii/` nell'elenco dei documenti, invii in qualsiasi formato registrati in §1.3) |
 | 27/09/2026 | `costi-ricorrenti.md` a v0.4.2: prezzi ricontrollati sulle fonti e nuova sezione sulla copertura dei servizi di terze parti |
 | 27/09/2026 | Aggiunto in §1.3 `invii/2026-09-27_costi_v0.4.docx`, versione semplice dei costi per datore di lavoro e cliente |
 | 27/09/2026 | `costi-ricorrenti.md` a v0.4.3 (solo euro, voci variabili con formula, esempi per 30 e 200 enti). In §1.3 la versione semplice dei costi passa da `.docx` a `invii/2026-09-27_costi_v0.4.md` (solo euro, formule); il `.docx`, mai inviato, è eliminato |
 | 27/09/2026 | Allineamento ed eliminazione delle ripetizioni: `richiesta.md` 0.4.3 (RT-3 allineato a W4), `workflow.md` 0.4.1, `domande-cliente.md` 0.4.4, `costi-ricorrenti.md` 0.4.4 (riscritto in forma lineare con i link delle fonti; firma in test verificata). Legenda dei simboli spostata qui da `richiesta.md`; corrispondenza tra domande della proposta e codici Q spostata in `domande-cliente.md` |
 | 27/09/2026 | Aggiunti `architettura.md` e `blueprint.md` (v0.4), ricostruiti da `architettura.md`, `blueprint-progetto.md`, `flussi-di-lavoro.md` e `mvp.md` della cartella `software.old` e adattati al repository (stack come proposta, nessuna stima inventata). `workflow.md` a v0.4.2 (diagrammi di W1, W4, W5; passo 🔸 7 di W4); `domande-cliente.md` a v0.4.5 (B1.10–B1.12, B2.6–B2.7). Aggiornati §1.2, dipendenze e §2.2; `CLAUDE.md` aggiornato (elenco dei documenti, codici Pn e Tn, dipendenze, procedura di aggiornamento) |
 | 27/09/2026 | Verifica di `architettura.md` e `blueprint.md` sulle fonti (con [D] confrontato con l'originale in `software.old/originali`: il testo coincide con la trascrizione): entrambi a v0.4.1, la conservazione digitale è richiesta da [D] e Q9 decide solo se va fatta a norma |
 | 27/09/2026 | Domande per il cliente: la proposta `invii/2026-09-27_proposta_v0.4.csv` (mai inviata) è eliminata e sostituita da `invii/2026-09-27_domande-cliente_v0.4.md` (domande e comunicazioni, senza riepilogo delle funzioni). `richiesta.md` 0.4.4 (Q25, Q26, nomi allineati a [X] per D13, rimando alla legenda corretto), `domande-cliente.md` 0.4.6, `architettura.md` e `blueprint.md` 0.4.2. `CLAUDE.md` aggiornato (esempio della cartella `invii/`) |
 | 27/09/2026 | `architettura.md` a v0.4.3: tolto dal vincolo "un solo sviluppatore" il riferimento alla manutenzione dal secondo anno |
 | 27/09/2026 | Verifica di allineamento: `richiesta.md` 0.4.5 (stato di M2 con Q25), `workflow.md` 0.4.3 (W1 passo 6 allineato ad `architettura.md`: link di attivazione) |
 | 27/09/2026 | `costi-ricorrenti.md` a v0.4.5: le voci variabili (§4) riorganizzate in "legate a un requisito, in attesa del cliente" e "facoltative"; §3 rinominato "Spese certe". Solo forma, nessuna cifra cambiata |
 | 27/09/2026 | `architettura.md` a v0.4.4: tolta l'indicazione (§7) che D11 avesse deciso le "ore di manutenzione" dal secondo anno; D11 decide solo che la gestione tecnica resta a Davide con contratto separato, non i termini né le ore |
 | 27/09/2026 | `invii/2026-09-27_domande-cliente_v0.4.md` non ancora inviato: §2 e §3 riformulati in tono più formale e sintetico, nessun contenuto o codice cambiato |
 | 27/09/2026 | B1.10 orientata su Django (Davide conosce Python, non ancora decisione formale): `architettura.md` a v0.4.5, `domande-cliente.md` a v0.4.7 |
@@ -0,0 +1,136 @@
 # Costi dei servizi per il primo anno
 **Gestionale per enti del Terzo Settore** · Versione 0.4 · 27/09/2026 · Importi in euro, IVA esclusa
 ---
 ## In breve
 - **Costi fissi: 1.330,53 €** per 12 mesi. Servono comunque, qualunque scelta facciate.
 - **Costi variabili:** dipendono dal numero di enti e da alcune vostre scelte. Per ognuno è indicato **come si calcola** (punto 2).
 - **Esempi di totale:** 2.600,53 € con 30 enti · 3.095,19 € con 200 enti (punto 3).
 - **Primo anno:** tutti questi costi sono a mio carico e compresi nel preventivo.
 - **Non comprende:** le ore di sviluppo, che sono nel preventivo.
 ---
 ## 1. Costi fissi
 | Voce | A cosa serve | Al mese | 12 mesi |
 |---|---|---|---|
 | Strumenti di sviluppo | Assistente con intelligenza artificiale che uso per scrivere il software | 90,00 € | **1.080,00 €** |
 | Ambiente di prova | Una copia del software per collaudare le funzioni senza usare dati reali | 5,99 € | **71,88 €** |
 | Server e sicurezza dei dati | Server in Europa, backup automatici, copia di sicurezza esterna, indirizzo internet del software (11,99 € l'anno) | 13,89 € | **178,65 €** |
 | Controllo del funzionamento | Avvisi se si verifica un errore o se il software non risponde | 0 € | **0 €** |
 | **Totale costi fissi** | | | **1.330,53 €** |
 ---
 ## 2. Costi variabili: come si calcolano
 ### 2.1 Firma digitale dei documenti
 Serve per far firmare all'ente offerta, informativa privacy e modulo antiriciclaggio (ed eventualmente libri sociali e verbali).
 **Una firma = un documento firmato.** Esempio: un nuovo ente che firma offerta, privacy e antiriciclaggio = 3 firme.
 | Tipo di firma | Costo annuo |
 |---|---|
 | **Semplice** (codice via SMS) | **1.248 €** fino a 500 firme l'anno · oltre 500: **1.248 € + 2 € per ogni firma in più** |
 | **Qualificata** | Costo della firma semplice **+ 10 € per ogni firma qualificata** (acquistate a pacchetti annuali da almeno 10), oppure **+ 15 €** l'una se acquistate singolarmente |
 | **Avanzata** | Prezzo solo su preventivo del fornitore |
 Esempi con firma semplice: 90 firme → 1.248 € · 500 firme → 1.248 € · 600 firme → 1.248 € + 2 € × 100 = **1.448 €**.
 Esiste un fornitore che parte da **360 € l'anno**: il numero di firme incluse si conosce solo con un preventivo, che chiederò se il volume lo rende conveniente.
 ### 2.2 Data certa sui documenti archiviati
 Ogni libro sociale o verbale approvato riceve una **marca temporale**, che ne certifica la data. Si pagano a pacchetti:
 | Pacchetto | Prezzo | Costo a documento |
 |---|---|---|
 | 20 marche | 6,00 € | 0,30 € |
 | 100 marche | 16,00 € | 0,16 € |
 | 250 marche | 37,50 € | 0,15 € |
 | 500 marche | 70,00 € | 0,14 € |
 **Costo annuo = pacchetti più convenienti per coprire i documenti archiviati nell'anno.**
 Esempi: 120 documenti → 100 + 20 = **22 €** · 800 documenti → 500 + 3 × 100 = **118 €**.
 ### 2.3 Conservazione digitale a norma dei libri sociali
 | Se… | Costo annuo |
 |---|---|
 | **non serve** | **0 €** |
 | serve, in **un unico archivio** a nome dello studio | **49,90 €** (1 GB incluso) **+ 25 € per ogni GB in più** |
 | serve, **a nome di ogni ente** | **49,90 € × numero di enti** (+ 25 € per ogni GB in più di ciascun archivio) |
 Esempi: un archivio da 3 GB → 49,90 € + 2 × 25 € = **99,90 €** · 200 enti con archivio da 1 GB → 49,90 € × 200 = **9.980 €**.
 È la voce che può pesare di più: se serve, verifichiamo insieme se basta un archivio unico.
 Nota: con questo servizio i documenti si caricano nell'archivio a mano; il caricamento automatico dal software richiede un fornitore diverso, con prezzo su preventivo.
 ### 2.4 Email professionali
 | Se… | Costo annuo |
 |---|---|
 | fino a 300 email al giorno, accettando il marchio del fornitore in fondo alle email | **0 €** |
 | senza marchio del fornitore, fino a 5.000 email al mese | **85,03 €** (pagamento annuale) |
 | oltre 5.000 email al mese | piano superiore, prezzo da verificare in base al volume |
 Consiglio la versione senza marchio: le circolari dello studio non devono riportare il marchio di un'altra azienda.
 ### 2.5 Spazio aggiuntivo per i documenti
 Serve solo se i documenti caricati (estratti conto, verbali, progetti) superano lo spazio del server.
 **Costo annuo = 0,69 € per ogni GB aggiuntivo** (0,0572 € per GB al mese).
 Esempi: 20 GB → **13,73 €** · 50 GB → **34,32 €**.
 ### 2.6 Fatturazione elettronica
 Non inclusa. Se serve, si quota a parte.
 ---
 ## 3. Totale del primo anno
 **Totale = 1.330,53 € + firma + data certa + conservazione + email + spazio aggiuntivo**
 Due esempi. Ipotesi, da sostituire con i vostri dati: firma semplice; 3 firme per ente; 4 documenti con data certa per ente l'anno.
 | Voce | 30 enti | 200 enti |
 |---|---|---|
 | Costi fissi | 1.330,53 € | 1.330,53 € |
 | Firma semplice | 90 firme → 1.248,00 € | 600 firme → 1.448,00 € |
 | Data certa | 120 documenti → 22,00 € | 800 documenti → 118,00 € |
 | Conservazione a norma | non serve → 0 € | archivio unico da 3 GB → 99,90 € |
 | Email | con marchio del fornitore → 0 € | senza marchio → 85,03 € |
 | Spazio aggiuntivo | nessuno → 0 € | 20 GB → 13,73 € |
 | **Totale (IVA esclusa)** | **2.600,53 €** | **3.095,19 €** |
 Con 200 enti e conservazione a nome di ogni ente, la conservazione passa da 99,90 € a 9.980 € e il totale a **12.975,29 €**.
 ### Se il periodo non è di 12 mesi
 Ogni mese in più o in meno a mio carico vale: **90,00 €** (strumenti di sviluppo) + **5,99 €** (ambiente di prova) + **13,89 €** (server, se già attivo).
 ---
 ## 4. Cosa ci serve per chiudere la cifra
 1. Quanti enti pensate di gestire.
 2. Che tipo di firma serve per offerte, privacy, antiriciclaggio e libri sociali.
 3. Se per i libri sociali serve la conservazione digitale a norma.
 4. Da quando parte il primo anno di servizi a mio carico: firma del contratto o avvio del software.
 ---
 ## 5. Chi paga
 - **Primo anno:** tutti i costi di questo documento sono a mio carico e compresi nel preventivo.
 - **Dal secondo anno:** i servizi (server, sicurezza dei dati, firma, email…) passano a vostro nome e li pagate direttamente, senza gli strumenti di sviluppo. La gestione tecnica si regola con il contratto di manutenzione.
 ---
 ## 6. Note
 - Importi IVA esclusa, basati sui prezzi pubblici dei fornitori al 27/09/2026: possono cambiare nel tempo.
 - Alcuni fornitori hanno il listino in valuta estera: i prezzi sono convertiti in euro al cambio della Banca Centrale Europea del 25/09/2026. L'importo addebitato può variare di poco con il cambio.
 - Tutti i dati restano su server nell'Unione Europea, nel rispetto del GDPR.
@@ -0,0 +1,67 @@
 # Domande sul gestionale
 **Gestionale per enti del Terzo Settore** · Versione 0.4 · 27/09/2026
 Ho analizzato il Word e l'Excel che mi avete mandato. Prima di preparare il preventivo mi servono le vostre risposte su alcuni punti (1), vi riassumo come ho impostato il resto (2) e vi chiedo alcuni materiali (3).
 ---
 ## 1. Domande
 Ogni risposta cambia in modo sensibile tempi o costi, oppure chiarisce un punto in cui Word ed Excel non dicono la stessa cosa.
 | N. | Domanda | Risposta |
 |---|---|---|
 | 1 | Quanti enti pensate di gestire, oggi e tra 3 anni? | |
 | 2 | Che firma serve per offerte, privacy, antiriciclaggio e libri sociali: semplice (codice via SMS), avanzata o qualificata? | |
 | 3 | Per i libri sociali chiedete la conservazione digitale: basta un archivio nel software con data certa (marca temporale), o serve la conservazione a norma presso un conservatore accreditato? | |
 | 4 | Il software deve fare anche la fattura elettronica, o bastano i proforma? Usate già un programma di fatturazione? | |
 | 5 | Gli estratti conto in PDF vanno letti in automatico o basta archiviarli? | |
 | 6 | Chi prepara lo schema dei progetti per i bandi, e per quando? In che formato va esportato il progetto? L'adattamento ai formulari dei bandi lo fate voi a mano? | |
 | 7 | In progettazione e bilancio sociale: (a) l'ente scrive e voi rivedete, (b) ognuno compila le sue parti, o (c) lavorate insieme sullo stesso documento? | |
 | 8 | Le circolari sono previste nella prima fase, insieme alla gestione del cliente, come nell'Excel. Nel Word sono tra le funzioni da aggiungere in un secondo momento: confermate che le volete subito? | |
 | 9 | Nel Word indicate la qualifica dell'ente (ODV, APS, ETS, impresa sociale, SOMS, rete, ente filantropico), nell'Excel la sezione di iscrizione al RUNTS. Sono lo stesso dato? Se sì, prevedo un solo campo | |
 ---
 ## 2. Come ho impostato il resto
 ### 2.1 Punti già decisi
 - **Word ed Excel:** in caso di discordanza prevale l'Excel; quanto presente in un solo documento è comunque incluso.
 - **Dati separati:** ogni ente accede esclusivamente ai propri dati; lo studio ha visibilità su tutti gli enti.
 - **Utilizzo:** applicazione web per computer, senza versione per smartphone; dati conservati nell'Unione Europea e trattati nel rispetto del GDPR.
 - **Dati esistenti:** il software viene attivato senza dati preesistenti; soci e volontari già presenti vanno inseriti manualmente. Un'importazione automatica da Excel può essere quotata separatamente.
 - **Servizi (server, email, firma, backup):** a carico dello scrivente e inclusi nel preventivo per il primo anno; dal secondo anno passano a vostro nome, nell'ambito di un contratto di manutenzione.
 ### 2.2 Funzioni definite in autonomia
 Non descritte nel dettaglio nei documenti ricevuti; sono state impostate come segue e saranno verificate in fase di collaudo. Eventuali osservazioni possono essere segnalate anche prima di tale fase.
 | Area | Come funziona |
 |---|---|
 | Offerte | Lo studio gestisce un catalogo di servizi con prezzo e IVA; un pacchetto è un insieme di servizi |
 | Offerte | Un'offerta rifiutata, o non firmata entro la scadenza, si chiude e lo studio riceve un avviso |
 | Accesso degli enti | Lo studio crea l'accesso per il referente di ogni ente |
 | Pagamenti | Lo studio registra i pagamenti ricevuti e chiude le scadenze saldate |
 | Anagrafica enti | Numero di soci e di volontari inseriti a mano, con accanto il conteggio automatico dalle anagrafiche |
 | Anagrafica persone | Una sola scheda per persona, anche con più ruoli (es. socio e volontario); libro soci e registro volontari prendono i dati da lì |
 | Libri sociali | Lo studio può rimandare un documento all'ente con le sue osservazioni, prima di approvarlo |
 | Libri sociali | Dopo l'archiviazione una voce non si modifica più: una cessazione o una correzione si registra come nuova voce collegata a quella originale |
 | Contabilità | Calendario delle scadenze uguale per tutti gli enti, con eccezioni per il singolo ente |
 | Contabilità | Se l'ente non carica i documenti entro la scadenza, riceve un sollecito e lo studio un avviso |
 | Contabilità | Lo studio controlla Modello D e relazione illustrativa prima dell'esportazione |
 | Circolari | Si possono mandare a tutti gli enti o solo ad alcuni |
 ---
 ## 3. Materiali da parte vostra
 Necessari per lo sviluppo delle funzioni indicate. Si richiede di indicare una data di consegna, da riportare nel contratto: un ritardo comporta uno slittamento dei tempi di realizzazione.
 | Materiale | Serve per | Entro il |
 |---|---|---|
 | Schema dei progetti per i bandi | Progettazione | |
 | Modelli di verbale (assemblea e organo di amministrazione) | Libri sociali | |
 | Modello di circolare | Circolari | |
 | Un estratto conto di esempio per ogni banca usata dagli enti | Caricamento della contabilità | |
 | Tariffe orarie per la valorizzazione del volontariato | Valutazione volontariato | |
@@ -1,17 +1,14 @@
 # Richiesta del cliente
 **Progetto:** Gestionale per enti del Terzo Settore
 **Documento:** `richiesta.md` (documento base: gli altri documenti si allineano a questo)
-**Versione:** 0.3.1 · **Data:** 27/09/2026 · **Stato:** Bozza, da validare con il cliente
+**Versione:** 0.4.5 · **Data:** 27/09/2026 · **Stato:** Bozza, da validare con il cliente
 **Allineato a:** fonti del cliente del 25/09/2026 · **Schema di versione:** vedi `indice-documenti.md`
 **Fonti:**
- **[D]** `fonti/2026-09-25/funzioni software.docx`: funzioni richieste, divise in "di base indispensabili" e "aggiuntive"
+- **[D]** `fonti/2026-09-25/funzioni software.docx`: funzioni richieste, divise in "di base indispensabili" e "aggiuntive" (originale ancora da copiare nella cartella; nel frattempo vale la trascrizione `funzioni software - testo estratto.md`)
 - **[X]** `fonti/2026-09-25/Software.xlsx`: tabella Moduli / Funzioni / Contenuti / Operatore / Note
-**Cosa contiene:** cosa deve fare il software e cosa è stato deciso.
+**Cosa contiene:** cosa deve fare il software e cosa è stato deciso. Contenuto degli altri documenti e simboli: `indice-documenti.md` §1.2 e §1.3.
 **Dove trovare il resto:** processi passo per passo in `workflow.md` · domande aperte, dubbi architetturali, rischi e verifiche legali in `domande-cliente.md` · costi in `costi-ricorrenti.md`.
 **Legenda:** ✅ deciso · ⏳ aperto (domanda in `domande-cliente.md`) · 🔸 ipotesi da confermare
 ---
@@ -35,20 +32,20 @@
 ## 2. Moduli
-**Fase:** fase 1 = funzioni che [D] chiama "di base indispensabili"; fase 2 = funzioni "aggiuntive". Eccezione: M8 in fase 1 (D3).
+**Fase:** fase 1 = funzioni che [D] chiama "di base indispensabili"; fase 2 = funzioni "aggiuntive". Eccezione: M8 in fase 1 (D3, ⏳ conferma Q26).
 **Stato:** *Definito* se nessun dubbio aperto ne cambia la struttura; altrimenti è indicata la domanda.
 | # | Modulo | Cosa fa | Fase | Chi inserisce i dati | Chi controlla / usa il risultato | Stato |
 |---|---|---|---|---|---|---|
-| M1 | Gestione cliente e contrattualistica | Offerte, firme, scadenziario e proforma dello studio verso gli enti | 1 | Studio | Ente (firma l'offerta, riceve i proforma) | Definito (dettagli: Q3, Q4, Q5) |
+| M1 | Gestione cliente e contrattualistica | Offerte, firme, scadenziario e proforma dello studio verso gli enti | 1 | Studio | Ente (firma l'offerta, riceve i proforma) | Definito (dettagli: Q4, Q5) |
-| M2 | Anagrafica enti | Scheda di ogni ente cliente | 1 | Studio | Studio | Definito |
+| M2 | Anagrafica enti | Scheda di ogni ente cliente | 1 | Studio | Studio | Definito (dettagli: Q25) |
-| M3 | Anagrafiche collegate | Registro di soci, volontari, dipendenti e altre persone dell'ente | 1 | Ente | Ente; i dati alimentano M4 e M7 | Definito (dettagli: Q8) |
+| M3 | Anagrafica stakeholder | Registro di soci, volontari, dipendenti e altre persone dell'ente | 1 | Ente | Ente; i dati alimentano M4 e M7 | Definito |
 | M4 | Libri sociali | Libro soci, registro volontari, verbali, con marca temporale | 1 | Ente | Studio controlla, poi stampa e archiviazione definitiva | Definito (dettagli: Q9) |
 | M5 | Contabilità | Documenti contabili, Modello D e relazione illustrativa | 1 | Ente (carica documenti, scrive la relazione) | Studio (imputa i movimenti sulle voci del Modello D) | Definito (dettagli: Q10) |
 | M6 | Progettazione | Stesura guidata di progetti per bandi | 1 | Ente e studio | Ente e studio | ⏳ Q13, Q19 |
-| M7 | Rendicontazione sociale | Stesura guidata del bilancio sociale | 2 | Ente e studio | Ente e studio | ⏳ Q14, Q19 |
+| M7 | Rendicontazione sociale | Stesura guidata del bilancio sociale | 2 | Ente e studio | Ente e studio | ⏳ Q19; Q14 prima della fase 2 |
-| M8 | Circolari | Comunicazioni dello studio agli enti su scadenze e adempimenti | 1 | Studio | Ente (via email e nell'app) | Definito |
+| M8 | Circolari | Comunicazioni dello studio agli enti su scadenze e adempimenti | 1 | Studio | Ente (via email e nell'app) | Definito (fase: ⏳ Q26) |
-| M9 | Valutazione volontariato | Time sheet di volontari e dipendenti, con valorizzazione delle ore | 2 | Studio | Studio | Definito (dettagli: Q15) |
+| M9 | Valutazione volontariato | Time sheet di volontari e dipendenti, con valorizzazione delle ore | 2 | Studio | Studio | Definito (Q15 prima della fase 2) |
 **Fase 1:** M1, M2, M3, M4, M5, M6, M8 · **Fase 2:** M7, M9.
@@ -64,7 +61,7 @@ Gestire il rapporto commerciale tra studio ed ente, dall'offerta all'incasso.
 | ID | Requisito | Fonte |
 |---|---|---|
-| RF-1.1 | Catalogo dei **servizi** dello studio, vendibili **singolarmente o a pacchetto** ⏳ Q3 | D |
+| RF-1.1 | Catalogo dei **servizi** dello studio, vendibili **singolarmente o a pacchetto**. 🔸 Gestito dallo studio: ogni servizio ha prezzo e aliquota IVA; un pacchetto è un insieme di servizi | D |
 | RF-1.2 | Composizione di **preventivi/offerte** a partire dal catalogo | D + X |
 | RF-1.3 | Nell'offerta vanno indicate **modalità di pagamento e scadenze** | D |
 | RF-1.4 | Invio dell'offerta all'ente e **firma digitale** per l'accettazione ⏳ Q4 | D + X |
@@ -87,24 +84,24 @@ Scheda completa di ciascun ente cliente, compilata dallo studio.
 | RF-2.4 | Partita IVA (se presente) | D + X | Facoltativa |
 | RF-2.5 | Data di costituzione | D | |
 | RF-2.6 | Numero e data di iscrizione al RUNTS | D + X | |
-| RF-2.7 | Sezione di iscrizione al RUNTS | X | Lista chiusa |
+| RF-2.7 | Sezione di iscrizione al RUNTS | X | Lista chiusa. ⏳ Q25: probabilmente coincide con RF-2.8 |
-| RF-2.8 | Qualifica: ODV, APS, ETS, Impresa sociale, SOMS, Rete, Ente filantropico | D | Lista chiusa |
+| RF-2.8 | Qualifica: ODV, APS, ETS, Impresa sociale, SOMS, Rete, Ente filantropico | D | Lista chiusa. ⏳ Q25: se coincide con RF-2.7, un solo campo con il nome di [X] e questi valori (D13) |
 | RF-2.9 | Attività di interesse generale (art. 5 CTS) previste da statuto e svolte | D + X | Selezione multipla dall'elenco di legge |
 | RF-2.10 | Eventuali attività diverse (art. 6 CTS) | D + X | Selezione multipla / testo |
 | RF-2.11 | Raccolta fondi continuativa con modalità commerciali (sì/no) | D | |
 | RF-2.12 | Raccolta fondi continuativa ordinaria (sì/no) | D | |
-| RF-2.13 | Numero soci | D + X | 🔸 Inserito a mano (Q7) |
+| RF-2.13 | Numero soci | D + X | 🔸 Inserito a mano; accanto si mostra il conteggio calcolato da M3 |
-| RF-2.14 | Numero volontari | D + X | 🔸 Inserito a mano (Q7) |
+| RF-2.14 | Numero volontari | D + X | 🔸 Inserito a mano; accanto si mostra il conteggio calcolato da M3 |
-### M3: Anagrafiche collegate (fase 1)
+### M3: Anagrafica stakeholder collegata all'ente (fase 1)
 Registro delle persone legate a ciascun ente, compilato dall'ente.
 | ID | Requisito | Fonte |
 |---|---|---|
 | RF-3.1 | Inserimento dei dati anagrafici delle persone collegate all'ente | D + X |
-| RF-3.2 | Categorie di persona: elenco definitivo da stabilire ⏳ Q8 | D + X |
+| RF-3.2 | Categorie di persona: tutte quelle citate nelle fonti (tabella sotto, D13). Nuove categorie o dati specifici per categoria si aggiungono con una migrazione (D12) | D + X |
-| RF-3.3 | Una persona può appartenere a più categorie ⏳ Q8 | 🔸 |
+| RF-3.3 | 🔸 Una persona può appartenere a più categorie: **una scheda per persona, con più ruoli**; libro soci e registro volontari prendono i dati da qui | 🔸 |
 Categorie citate nelle fonti:
@@ -126,8 +123,8 @@ Tenuta digitale dei libri obbligatori dell'ente, con valore probatorio.
 | ID | Requisito | Fonte |
 |---|---|---|
-| RF-4.1 | **Libro soci**: data delibera di ammissione, dati anagrafici, contatti, data cessazione/decadenza, note, firma operatore | D + X |
+| RF-4.1 | **Libro soci**: data di ammissione (per [D] è la data della delibera di ammissione), dati anagrafici, contatti, data di cessazione (per [D] anche decadenza), note, firma operatore | D + X |
-| RF-4.2 | **Registro volontari**: data inizio, dati anagrafici, contatti, data fine, note, firma operatore | D + X |
+| RF-4.2 | **Registro volontari**: data di ammissione (per [D] inizio del volontariato), dati anagrafici, contatti, data di cessazione (per [D] fine del volontariato), note, firma operatore | D + X |
 | RF-4.3 | **Libro verbali assemblea soci**: redazione dei verbali | D + X |
 | RF-4.4 | **Libro verbali organo di amministrazione**: redazione dei verbali | D + X |
 | RF-4.5 | **Marcatura temporale** dei documenti | D + X |
@@ -140,7 +137,7 @@ Raccolta dei documenti contabili dell'ente, rendiconto di cassa e relazione illu
 | ID | Requisito | Fonte |
 |---|---|---|
-| RF-5.1 | **Alert all'ente** alle scadenze per il caricamento dei documenti; calendario **uguale per tutti gli enti, ma modificabile** ⏳ Q12 | D + D7 |
+| RF-5.1 | **Alert all'ente** alle scadenze per il caricamento dei documenti; calendario **uguale per tutti gli enti, ma modificabile**. 🔸 Calendario comune con eccezioni per singolo ente | D + D7 |
 | RF-5.2 | Caricamento degli **estratti conto bancari** trimestrali (Excel o PDF) ⏳ Q10 | D + X |
 | RF-5.3 | Caricamento della **prima nota cassa** trimestrale (Excel) | D + X |
 | RF-5.4 | Caricamento dei **rendiconti delle raccolte fondi pubbliche occasionali** | D |
@@ -168,7 +165,7 @@ Raccolta guidata dei dati per il bilancio sociale, riusando i dati già presenti
 |---|---|---|
 | RF-7.1 | Procedura guidata per redigere il bilancio sociale | D + X |
 | RF-7.2 | **Estrazione automatica** dei dati già presenti (anagrafica ente, soci, volontari, dati economici…) | D |
-| RF-7.3 | Sezioni: **lettera del presidente** [X], **serie di dati standard** [D], identità dell'ente, principali stakeholder, utenti, obiettivi e attività, situazione economico-finanziaria, relazione dell'organo di controllo ⏳ Q14 | D + X |
+| RF-7.3 | Sezioni: **lettera del presidente** [X], **serie di dati standard** [D], identità dell'ente, principali stakeholder, utenti, obiettivi e attività, situazione economico-finanziaria, relazione dell'organo di controllo ⏳ Q14, da chiedere prima della fase 2 | D + X |
 | RF-7.4 | Lavoro condiviso tra ente e studio ⏳ Q19 | X |
 ### M8: Circolari (fase 1)
@@ -184,7 +181,7 @@ Raccolta guidata dei dati per il bilancio sociale, riusando i dati già presenti
 |---|---|---|
 | RF-9.1 | Inserimento del **time sheet** di volontari **e dipendenti** | D |
 | RF-9.2 | Per ogni registrazione: tipo di attività, ore dedicate, ruolo/qualifica | D + X |
-| RF-9.3 | **Valorizzazione economica** di ogni ora in base all'attività ⏳ Q15 | D |
+| RF-9.3 | **Valorizzazione economica** di ogni ora in base all'attività ⏳ Q15, da chiedere prima della fase 2 | D |
 | RF-9.4 | L'inserimento è fatto dallo **studio** | X + D4 |
 ---
@@ -197,7 +194,7 @@ Non sono scritti come moduli nelle fonti, ma derivano da quanto richiesto.
 |---|---|---|
 | RT-1 | **Separazione dei dati tra enti**: ogni ente vede solo i propri dati, lo studio li vede tutti | D2 |
 | RT-2 | **Ruoli e permessi** distinti per studio ed ente | Colonna "Operatore" di [X] |
-| RT-3 | **Flusso di approvazione** comune (bozza → in revisione → approvato/respinto → archiviato) | M4, e probabilmente M5–M7 |
+| RT-3 | **Flusso di approvazione** comune: bozza → in revisione → 🔸 da correggere (si torna in bozza) oppure approvato → archiviato. Passi in W4 | M4, e probabilmente M5–M7 |
 | RT-4 | **Notifiche**: email + notifiche nell'app | M1, M5, M8 |
 | RT-5 | **Firma elettronica** dei documenti ⏳ Q4 | M1, M4 |
 | RT-6 | **Marca temporale** e **conservazione digitale** ⏳ Q9 | M4 |
@@ -205,11 +202,12 @@ Non sono scritti come moduli nelle fonti, ma derivano da quanto richiesto.
 | RT-8 | **Importazione file** (Excel, PDF) per i documenti contabili | M5 |
 | RT-9 | **Registro delle operazioni** (audit trail): chi ha fatto cosa e quando | Valore probatorio dei libri + GDPR |
 | RT-10 | **Conformità GDPR** (§5) | Dati personali di soci, volontari, dipendenti, clienti |
-| RT-11 | Dimensionamento: circa **100 utenti** ⏳ Q1, Q2 | Contesto di progetto |
+| RT-11 | Dimensionamento: circa **100 utenti** ⏳ Q1 | Contesto di progetto |
 | RT-12 | **Applicazione web** usata da computer; nessun requisito per smartphone o accessibilità | D9 |
-| RT-13 | **Hosting nell'Unione Europea** (il cliente non ha preferenze; l'UE è richiesta dal GDPR) | D9 + §5 |
+| RT-13 | **Hosting nell'Unione Europea** (il cliente non ha preferenze; l'UE evita i trasferimenti extra-UE e semplifica la conformità al GDPR) | D9 + §5 |
 | RT-14 | **Nessuna migrazione di dati** all'avvio: il sistema parte vuoto | D8 |
 | RT-15 | **Trasferibilità dei servizi di produzione:** a fine primo anno server, dominio, backup, email, firma, marche temporali ed eventuale conservazione passano al cliente senza interruzioni né perdita di dati; fornitori che permettono il trasferimento di account o contratto; documento di consegna con accessi, configurazioni e procedure | D10, D11 |
 | RT-16 | **Database PostgreSQL.** Ogni modifica della struttura dei dati si fa con **migrazioni** versionate insieme al codice, applicate identiche in test e in produzione; nessuna modifica manuale del database in produzione | D12 |
 ---
@@ -237,40 +235,42 @@ Il sistema tratta **molti dati personali di persone che non sono utenti del soft
 | # | Punto | [D] | [X] | Esito |
 |---|---|---|---|---|
-| 1 | Circolari | Funzione aggiuntiva (fase 2) | Dentro "Gestione cliente" | ✅ D3: fase 1 |
+| 1 | Circolari | Funzione aggiuntiva (fase 2) | Dentro "Gestione cliente", senza fase | ✅ D3: fase 1, ⏳ conferma Q26 |
 | 2 | Scadenziario e proforma | Non citati | Presenti | ✅ Inclusi (RF-1.7, RF-1.8) |
-| 3 | Campi anagrafica ente | Data costituzione, qualifica, raccolte fondi | Sede, sezione RUNTS | 🔸 Unione dei campi (Q20) |
+| 3 | Campi anagrafica ente | Data costituzione, qualifica, raccolte fondi | Sede, sezione RUNTS | ✅ D13: inclusi tutti |
-| 4 | Categorie di persone | 7 categorie | 6 categorie, in parte diverse | ⏳ Q8 |
+| 4 | Categorie di persone | 7 categorie | 6 categorie, in parte diverse | ✅ D13: incluse tutte |
-| 5 | Libri sociali | Firma operatore, note, conservazione digitale | Contatti | 🔸 Unione dei campi (Q20) |
+| 5 | Libri sociali | Firma operatore, note, conservazione digitale | Contatti | ✅ D13: inclusi tutti |
-| 6 | Contabilità | Alert, raccolte fondi occasionali, Modello D, relazione illustrativa | Imputazione dei singoli movimenti | 🔸 Unione: [X] descrive *come* si arriva al Modello D (Q20) |
+| 6 | Contabilità | Alert, raccolte fondi occasionali, Modello D, relazione illustrativa | Imputazione dei singoli movimenti | ✅ D13: inclusi tutti; [X] descrive *come* si arriva al Modello D |
-| 7 | Sezioni progettazione | Contiene "Costi" | Contiene "Obiettivi" e "Risorse" | 🔸 Unione delle sezioni (Q20) |
+| 7 | Sezioni progettazione | Contiene "Costi" | Contiene "Obiettivi" e "Risorse" | ✅ D13: incluse tutte |
 | 8 | Rendicontazione sociale | "Serie di dati standard" | "Lettera del presidente"; descrizione copiata da M6 | ⏳ Q14 |
 | 9 | Time sheet: chi inserisce | Non indicato | Operatore interno | ✅ D4: lo studio |
-| 10 | Valorizzazione oraria | Presente | Assente, ma c'è "ruolo/qualifica" | 🔸 Unione (Q20) |
+| 10 | Valorizzazione oraria | Presente | Assente, ma c'è "ruolo/qualifica" | ✅ D13: inclusi entrambi |
-Le righe "Unione" sono una proposta di chi scrive, non una richiesta del cliente.
+Regola generale: D13.
 ---
 ## 7. Decisioni
-Decisioni indicate da Davide: D1–D9 il 25/09/2026, D10–D11 il 27/09/2026. Vanno approvate dal cliente con la versione 1.0 (Q18).
+Decisioni indicate da Davide: D1–D9 il 25/09/2026, D10–D13 il 27/09/2026. Vanno approvate dal cliente con la versione 1.0 (Q18).
 | # | Decisione | Motivo / origine | Requisiti toccati |
 |---|---|---|---|
 | D1 | Interno = studio, esterno = ente | Le fonti usano "interno" in modi diversi; si adotta la convenzione di [X] | §1.2 |
 | D2 | Piattaforma multi-ente: uno studio gestisce molti enti clienti | Conferma del modello di business | RT-1 |
-| D3 | Circolari (M8) in fase 1 | [D] le mette in fase 2, [X] in "Gestione cliente": si segue [X] | M8 |
+| D3 | Circolari (M8) in fase 1 | [D] le mette in fase 2, [X] in "Gestione cliente": si segue [X]. [X] però non indica le fasi, quindi non è un vero conflitto tra le fonti: conferma del cliente in Q26 | M8 |
 | D4 | Il time sheet (M9) lo inserisce lo studio | [D] non lo dice, [X] indica l'operatore interno: si segue [X]. Non serve un nuovo tipo di utente | RF-9.4 |
 | D5 | Circolari via email e nell'app | Risposta a Q6 | RF-8.2, RT-4 |
 | D6 | Imputazione contabile direttamente sulle voci del Modello D | Risposta a Q11 | RF-5.5 |
-| D7 | Scadenze degli alert uguali per tutti gli enti, ma modificabili | Risposta a Q12 (resta una precisazione) | RF-5.1 |
+| D7 | Scadenze degli alert uguali per tutti gli enti, ma modificabili | Risposta a Q12 (la precisazione è coperta dall'ipotesi in RF-5.1) | RF-5.1 |
 | D8 | Nessuna migrazione di dati all'avvio | Risposta a Q16 | RT-14 |
 | D9 | Nessun requisito su smartphone, accessibilità o hosting | Risposta a Q17 | RT-12, RT-13 |
 | D10 | Primo anno di produzione: servizi intestati a Davide, che li paga; costi nel preventivo | Risposta a Q21 | RT-15 |
 | D11 | Dal secondo anno servizi intestati al cliente, che li paga; gestione tecnica a Davide con contratto di manutenzione separato | Risposta a Q22 | RT-15 |
 | D12 | Database **PostgreSQL**; ogni cambiamento della struttura dei dati tramite **migrazioni** | Dati fortemente relazionali (enti, persone, ruoli, libri, movimenti) con vincoli di integrità; separazione dei dati per ente anche nel database, con la row-level security (RT-1); open source, senza licenze, e trasferibile tra fornitori (RT-15). Le migrazioni permettono di recepire in modo tracciato e ripetibile le risposte del cliente che cambiano la struttura dei dati | RT-16, RF-3.2 |
 | D13 | Tra le fonti prevale l'Excel [X] in caso di conflitto; i campi e le funzioni presenti in una sola fonte si includono | Risposta a Q20 | §6 |
-**Ipotesi 🔸 in attesa di conferma:** RF-2.13 e RF-2.14 inseriti a mano (Q7); righe "Unione" del §6 (Q20).
+**Ipotesi 🔸 adottate** (al posto di domande al cliente, da validare con il cliente al collaudo; eventuali cambi della struttura dei dati con migrazioni, D12): RF-1.1 catalogo servizi · RF-2.13–2.14 conteggi · RF-3.3 una scheda per persona con più ruoli · RF-5.1 eccezioni per singolo ente · passi 🔸 di `workflow.md`.
 ---
@@ -282,10 +282,16 @@ Decisioni indicate da Davide: D1–D9 il 25/09/2026, D10–D11 il 27/09/2026. Va
 | 0.2 | 25/09/2026 | Risposte a Q6, Q7, Q11, Q12, Q13, Q16, Q17 (D5–D9); Q8 e Q14 divise in sotto-domande; aggiunte Q20 e RT-12, RT-13, RT-14; aggiunto il registro delle decisioni |
 | 0.3 | 27/09/2026 | Decisioni D10 e D11; chiuse Q21 e Q22; aggiunti RT-15 e Q23; aggiornati ruoli privacy e rischi |
 | 0.3.1 | 27/09/2026 | Riorganizzazione senza modifiche ai requisiti: spostati in `domande-cliente.md` domande, spiegazioni delle domande, dubbio C, rischi e verifiche legali; tolte le note su costi e scelte progettuali (già in `costi-ricorrenti.md` e `domande-cliente.md` parte B); tolto il flusso complessivo (già in `workflow.md`); motivazioni dei dubbi A e B spostate nella tabella delle decisioni |
 | 0.4 | 27/09/2026 | Decisioni D12 (PostgreSQL con migrazioni, RT-16) e D13 (priorità all'Excel in caso di conflitto, chiude Q20); domande Q2, Q3, Q7, Q8, Q12 sostituite da ipotesi 🔸 (RF-1.1, RF-2.13–2.14, RF-3.2–3.3, RF-5.1); Q14 e Q15 rimandate a prima della fase 2 |
 | 0.4.1 | 27/09/2026 | Allineamento: indicato che l'originale di [D] non è ancora nella cartella delle fonti |
 | 0.4.2 | 27/09/2026 | Allineamento: corretta la motivazione di RT-13 (il GDPR non impone l'hosting UE, lo rende più semplice) |
 | 0.4.3 | 27/09/2026 | Allineamento senza nuovi requisiti: gli stati di RT-3 riprendono il passo 🔸 "da correggere" già adottato in W4 (prima "respinto", in contrasto con il workflow); tolti legenda e "dove trovare il resto", ora solo in `indice-documenti.md` |
 | 0.4.4 | 27/09/2026 | Verifica sulle fonti, senza nuovi requisiti: aggiunte le domande Q25 (qualifica e sezione RUNTS forse sono lo stesso campo, RF-2.7–2.8) e Q26 (conferma di D3: [X] non indica le fasi); nomi allineati a [X] come vuole D13 (M3 "Anagrafica stakeholder collegata all'ente"; date di ammissione e cessazione in RF-4.1 e RF-4.2, con le precisazioni di [D]); corretto il rimando alla legenda dei simboli (§1.3 dell'indice) |
 | 0.4.5 | 27/09/2026 | Allineamento: lo stato di M2 in §2 indica la domanda Q25, come per gli altri moduli con dettagli aperti |
 ---
 ## Stato
- **Fase corrente:** analisi dei requisiti, bozza v0.3.1.
+- **Fase corrente:** analisi dei requisiti, bozza v0.4.5.
- **Decisioni prese:** D1–D11. Fase 1 = M1–M6 + M8; fase 2 = M7 + M9.
+- **Decisioni prese:** D1–D13 (§7); fasi dei moduli al §2.
 - **Prossimo passo:** risposte del cliente alle domande aperte (`domande-cliente.md`), poi versione 1.0 dei requisiti.
@@ -1,37 +1,36 @@
 # Workflow del software
 **Progetto:** Gestionale per enti del Terzo Settore
 **Documento:** `workflow.md`
-**Versione:** 0.3.1 · **Data:** 27/09/2026 · **Stato:** Bozza, da validare con il cliente
+**Versione:** 0.4.3 · **Data:** 27/09/2026 · **Stato:** Bozza, da validare con il cliente
-**Allineato a:** `richiesta.md` v0.3 · **Schema di versione:** vedi `indice-documenti.md`
+**Allineato a:** `richiesta.md` v0.4 · **Schema di versione:** vedi `indice-documenti.md`
 ---
 ## 0. Regole del documento
-1. **Il workflow deriva dalla richiesta.** Ogni passo cita il requisito (RF, RT), la decisione (D) o la domanda (Q) di `richiesta.md` da cui nasce. Quando la richiesta cambia, si aggiornano i passi che ne citano i codici.
+1. **Il workflow deriva dalla richiesta.** Ogni passo cita il requisito (RF, RT), la decisione (D) o la domanda (Q) da cui nasce. Quando la richiesta cambia, si aggiornano i passi che ne citano i codici.
-2. **Tre tipi di passo:**
+2. **Tipi di passo:** senza simbolo = scritto nelle fonti · 🔸 = dedotto, necessario perché il processo funzioni (ipotesi adottata, `richiesta.md` §7) · ⏳ = dipende da una domanda aperta; il passo descrive l'ipotesi di lavoro.
   - senza simbolo: scritto nelle fonti;
   - 🔸 **dedotto**: non è scritto, ma serve perché il processo funzioni. La domanda di conferma è in `domande-cliente.md` A4;
   - ⏳ **aperto**: dipende da una domanda senza risposta (in `domande-cliente.md`); il passo descrive l'ipotesi di lavoro.
 3. **Come si legge un passo:** chi lo fa, cosa fa, cosa fa il sistema, riferimento.
-**Attori:** **Studio** (operatore interno) · **Ente** (operatore esterno) · **Sistema** (azioni automatiche).
+**Attori:** Studio ed Ente come in `richiesta.md` §1.2, più il **Sistema** (azioni automatiche).
 ---
 ## 1. Mappa dei workflow
-| # | Workflow | Moduli | Fase | Frequenza | Stato |
+La fase di ogni workflow è quella del suo modulo (`richiesta.md` §2).
-|---|---|---|---|---|---|
+
-| W1 | Acquisizione e attivazione di un ente | M1, M2 | 1 | Una volta per ente | Definito |
+| # | Workflow | Moduli | Frequenza | Stato |
-| W2 | Scadenziario pagamenti e proforma | M1 | 1 | Alle scadenze dell'offerta | Definito (⏳ Q5) |
+|---|---|---|---|---|
-| W3 | Gestione delle persone dell'ente | M3 | 1 | Continua | ⏳ Q8 |
+| W1 | Acquisizione e attivazione di un ente | M1, M2 | Una volta per ente | Definito |
-| W4 | Tenuta dei libri sociali | M4 | 1 | A ogni evento (ammissione, cessazione, riunione) | Definito (⏳ Q4, Q9) |
+| W2 | Scadenziario pagamenti e proforma | M1 | Alle scadenze dell'offerta | Definito (⏳ Q5) |
-| W5 | Ciclo contabile | M5 | 1 | Trimestrale + annuale | Definito (⏳ Q10, Q12) |
+| W3 | Gestione delle persone dell'ente | M3 | Continua | Definito (🔸 RF-3.3) |
-| W6 | Stesura di un progetto | M6 | 1 | A ogni bando | ⏳ Q13, Q19 |
+| W4 | Tenuta dei libri sociali | M4 | A ogni evento (ammissione, cessazione, riunione) | Definito (⏳ Q4, Q9) |
-| W7 | Invio delle circolari | M8 | 1 | Quando serve | Definito |
+| W5 | Ciclo contabile | M5 | Trimestrale + annuale | Definito (⏳ Q10) |
-| W8 | Bilancio sociale | M7 | 2 | Annuale | ⏳ Q14, Q19 |
+| W6 | Stesura di un progetto | M6 | A ogni bando | ⏳ Q13, Q19 |
-| W9 | Time sheet e valorizzazione del volontariato | M9 | 2 | Periodica | ⏳ Q15 |
+| W7 | Invio delle circolari | M8 | Quando serve | Definito |
 | W8 | Bilancio sociale | M7 | Annuale | ⏳ Q14, Q19 |
 | W9 | Time sheet e valorizzazione del volontariato | M9 | Periodica | ⏳ Q15 |
 ### Ciclo di vita di un ente
@@ -43,11 +42,11 @@ flowchart LR
    B --> E[W5 Contabilità trimestrale]
    E --> F[W5 Modello D e relazione annuale]
    B --> G[W6 Progetti]
-    F --> H[W8 Bilancio sociale - fase 2]
+    F --> H[W8 Bilancio sociale]
    C --> H
    B --> I[W2 Proforma alle scadenze]
    B --> J[W7 Circolari]
-    C --> K[W9 Time sheet - fase 2]
+    C --> K[W9 Time sheet]
 ```
 ---
@@ -59,16 +58,27 @@ flowchart LR
 | # | Chi | Azione | Sistema | Rif. |
 |---|---|---|---|---|
-| 1 | Studio | Compone l'offerta scegliendo servizi singoli o pacchetti dal catalogo | Calcola il totale | RF-1.1, RF-1.2 (⏳ Q3) |
+| 1 | Studio | Compone l'offerta scegliendo servizi singoli o pacchetti dal catalogo | Calcola il totale | RF-1.1 (🔸), RF-1.2 |
 | 2 | Studio | Indica modalità di pagamento e scadenze | Salva le condizioni, da cui nasce lo scadenziario (W2) | RF-1.3 |
 | 3 | Studio | Invia l'offerta all'ente | Allega informativa privacy e modulo antiriciclaggio; notifica l'ente | RF-1.4–1.6 |
 | 4 | Ente | Legge e firma offerta, presa visione privacy e dati antiriciclaggio | Registra le firme con data e ora | RF-1.4–1.6 (⏳ Q4 tipo di firma) |
 | 4b | Ente | 🔸 Rifiuta l'offerta, oppure l'offerta scade senza firma | Offerta chiusa, studio avvisato | 🔸 dedotto |
 | 5 | Studio | Compila l'anagrafica dell'ente | Controlla i campi obbligatori | RF-2.1–2.14 |
-| 6 | Studio | 🔸 Crea l'accesso per il referente dell'ente | Invia le credenziali; l'ente vede solo i propri dati | RT-1, RT-2 (🔸 dedotto) |
+| 6 | Studio | 🔸 Crea l'accesso per il referente dell'ente | Invia un link di attivazione a scadenza, mai una password; l'ente vede solo i propri dati | RT-1, RT-2 (🔸 dedotto) |
 **Stati dell'offerta:** bozza → inviata → firmata · 🔸 rifiutata · 🔸 scaduta.
 ```mermaid
 flowchart TD
    A[Studio: compone l'offerta<br/>e le condizioni di pagamento] --> B[Studio: invia l'offerta<br/>con privacy e antiriciclaggio]
    B --> C{Ente}
    C -->|firma| D[Offerta firmata]
    C -->|🔸 rifiuta o non firma in tempo| E[Offerta chiusa<br/>studio avvisato]
    D --> F[Studio: compila l'anagrafica dell'ente]
    F --> G[Studio: 🔸 crea l'accesso del referente]
    D --> H[W2 Scadenziario]
 ```
 ---
 ## 3. W2: Scadenziario pagamenti e proforma (M1)
@@ -93,8 +103,8 @@ flowchart LR
 | # | Chi | Azione | Sistema | Rif. |
 |---|---|---|---|---|
 | 1 | Ente | Inserisce o modifica la persona: anagrafica, contatti, categoria | Controlla i duplicati | RF-3.1, RF-3.2 |
-| 2 | Ente | ⏳ Assegna uno o più ruoli (es. socio e volontario) | ⏳ Una scheda per persona con più ruoli | RF-3.3 (⏳ Q8.c) |
+| 2 | Ente | Assegna uno o più ruoli (es. socio e volontario) | Una scheda per persona con più ruoli | RF-3.3 (🔸) |
-| 3 | Sistema | — | ⏳ Se la persona è socio o volontario, prepara la voce nel libro soci o nel registro volontari (W4) | ⏳ Q8.c |
+| 3 | Sistema | — | Se la persona è socio o volontario, prepara la voce nel libro soci o nel registro volontari (W4) | RF-3.3 (🔸) |
 ---
@@ -112,9 +122,20 @@ flowchart LR
 | 4 | Studio | Approva | Stato "approvato" | RF-4.7 |
 | 5 | Sistema | — | Applica la marca temporale e archivia in modo definitivo; il documento non è più modificabile | RF-4.5, RF-4.6 (⏳ Q9) |
 | 6 | Studio / Ente | Stampa | Genera il PDF | RF-4.7, RT-7 |
 | 7 | Ente | 🔸 Registra la cessazione o corregge una voce già archiviata | Crea una nuova voce collegata all'originale, che resta invariata; la nuova voce riparte dal passo 1 | 🔸 dedotto (RF-4.1, RF-4.2: data di cessazione; RT-9) |
-**Stati:** bozza → in revisione → 🔸 da correggere → approvato → archiviato.
+**Stati:** quelli del flusso di approvazione comune (RT-3), riusato in W5, W6 e W8.
-**Flusso di approvazione:** è lo stesso flusso comune a più moduli (RT-3), riusato in W6 e W8.
+
 ```mermaid
 flowchart TD
    A[Ente: compila la voce o il verbale] --> B[Ente: firma come operatore e invia]
    B --> C{Studio: controlla}
    C -->|🔸 osservazioni| A
    C -->|approva| D[Sistema: marca temporale e archiviazione<br/>non più modificabile]
    D --> E[Stampa]
    D -.->|🔸 cessazione o correzione| F[Ente: nuova voce collegata]
    F --> B
 ```
 ---
@@ -128,12 +149,23 @@ flowchart LR
 | # | Chi | Azione | Sistema | Rif. |
 |---|---|---|---|---|
-| 1 | Studio | Imposta il calendario delle scadenze, uguale per tutti gli enti | ⏳ Ammette modifiche anche per il singolo ente | RF-5.1, D7 (⏳ Q12) |
+| 1 | Studio | Imposta il calendario delle scadenze, uguale per tutti gli enti | Ammette eccezioni per il singolo ente | RF-5.1 (🔸), D7 |
 | 2 | Sistema | — | Alla scadenza manda all'ente l'alert per caricare i documenti | RF-5.1, RT-4 |
 | 3 | Ente | Carica gli estratti conto (Excel o PDF), la prima nota cassa (Excel) e gli eventuali rendiconti delle raccolte fondi occasionali | Archivia i file; ⏳ estrae i movimenti da Excel/CSV | RF-5.2–5.4 (⏳ Q10) |
 | 4 | Sistema | 🔸 — | 🔸 Se l'ente non carica, manda un sollecito e avvisa lo studio | 🔸 dedotto |
 | 5 | Studio | Imputa ogni movimento a una voce del Modello D | Salva l'imputazione | RF-5.5, D6 |
 ```mermaid
 flowchart TD
    A[Studio: calendario delle scadenze] --> B[Sistema: alert all'ente]
    B --> C[Ente: carica estratti conto,<br/>prima nota e rendiconti raccolte fondi]
    B -.->|🔸 nessun caricamento| D[Sistema: sollecito all'ente<br/>e avviso allo studio]
    D -.-> C
    C --> E[Sistema: archivia i file<br/>⏳ estrae i movimenti da Excel/CSV]
    E --> F[Studio: imputa i movimenti<br/>sulle voci del Modello D]
    F -->|fine esercizio| G[6.2 Chiusura annuale]
 ```
 ### 6.2 Chiusura annuale
 **Inizio:** fine esercizio · **Fine:** Modello D e relazione pronti da allegare al bilancio.
@@ -152,12 +184,12 @@ flowchart LR
 **Scopo:** preparare un progetto da presentare a un bando.
 **Inizio:** l'ente o lo studio avvia un nuovo progetto · **Fine:** progetto esportato.
-> ⏳ **Ipotesi di lavoro (Q19, opzione a):** l'ente scrive e lo studio rivede, con lo stesso flusso di W4. Con le opzioni (b) o (c) (`domande-cliente.md` B4.3) questo workflow va riscritto.
+> ⏳ **Ipotesi di lavoro (Q19, opzione a):** l'ente scrive e lo studio rivede, con lo stesso flusso di W4. Con le opzioni (b) o (c) di Q19 questo workflow va riscritto.
 | # | Chi | Azione | Sistema | Rif. |
 |---|---|---|---|---|
 | 1 | Ente o Studio | Crea il progetto | Apre la procedura guidata | RF-6.1 |
-| 2 | Ente | Compila le sezioni: contesto, bisogni, idea, obiettivi, attività, risorse, cronoprogramma, costi, piano economico-finanziario | Guida sezione per sezione | RF-6.2 (⏳ Q13 schema di dettaglio) |
+| 2 | Ente | Compila le sezioni del progetto | Guida sezione per sezione | RF-6.2 (⏳ Q13 schema di dettaglio) |
 | 3 | Ente | Invia allo studio | Stato "in revisione" | RF-6.4 (⏳ Q19) |
 | 4 | Studio | Rivede; approva o rimanda con osservazioni | Flusso di approvazione (RT-3) | RF-6.4 (⏳ Q19) |
 | 5 | Studio / Ente | Esporta e adatta al formulario del bando | ⏳ Esporta in Word/PDF | RF-6.3 (⏳ Q13) |
@@ -179,7 +211,7 @@ flowchart LR
 ---
-## 9. W8: Bilancio sociale (M7), fase 2
+## 9. W8: Bilancio sociale (M7)
 **Scopo:** redigere il bilancio sociale riusando i dati già presenti.
 **Inizio:** fine esercizio · **Fine:** bilancio sociale esportato.
@@ -189,13 +221,13 @@ flowchart LR
 | # | Chi | Azione | Sistema | Rif. |
 |---|---|---|---|---|
 | 1 | Ente o Studio | Avvia il bilancio sociale dell'anno | Precompila con i dati già presenti: anagrafica ente (W1), persone (W3), dati economici (W5) | RF-7.1, RF-7.2 |
-| 2 | Ente | Completa le sezioni: lettera del presidente, dati standard, identità, stakeholder, utenti, obiettivi e attività, situazione economico-finanziaria, relazione dell'organo di controllo | Procedura guidata | RF-7.3 (⏳ Q14) |
+| 2 | Ente | Completa le sezioni del bilancio sociale | Procedura guidata | RF-7.3 (⏳ Q14) |
 | 3 | Studio | Rivede; approva o rimanda | Flusso di approvazione (RT-3) | RF-7.4 (⏳ Q19) |
 | 4 | Studio / Ente | Esporta | Genera PDF/Word | RT-7 |
 ---
-## 10. W9: Time sheet e valorizzazione del volontariato (M9), fase 2
+## 10. W9: Time sheet e valorizzazione del volontariato (M9)
 **Scopo:** registrare le ore di volontari e dipendenti e darne un valore economico.
 **Inizio:** l'ente comunica le ore · **Fine:** ore registrate e valorizzate.
@@ -216,10 +248,16 @@ flowchart LR
 | 0.2 | 25/09/2026 | 0.2 | Prima stesura, allineata a `richiesta.md` v0.2 |
 | 0.3 | 27/09/2026 | 0.3 | Solo allineamento di versione: D10, D11 e RT-15 riguardano la gestione dei servizi, non i processi del software. Nessun passo modificato |
 | 0.3.1 | 27/09/2026 | 0.3 | Riorganizzazione senza modifiche ai passi: tolti le righe "Domande aperte" (ripetevano la colonna Rif.), la procedura di aggiornamento (è in `indice-documenti.md`) e il §12 dei passi da confermare (spostato in `domande-cliente.md` A4) |
 | 0.3.2 | 27/09/2026 | 0.3 | Aggiornato il rimando alle conferme dei passi 🔸: ora sono in `domande-cliente.md` A3 |
 | 0.3.3 | 27/09/2026 | 0.3 | Aggiornati i rimandi a `domande-cliente.md` dopo la sua semplificazione (conferme in §2; opzioni di Q19 nella domanda stessa) |
 | 0.4 | 27/09/2026 | 0.4 | Allineato a `richiesta.md` v0.4: i passi di W1, W3 e W5 legati a Q3, Q8, Q12 diventano ipotesi 🔸 di `richiesta.md`; i passi 🔸 si validano al collaudo invece che con domande |
 | 0.4.1 | 27/09/2026 | 0.4 | Tolte le ripetizioni di `richiesta.md`: descrizione degli attori, fase dei workflow (è quella del modulo), elenchi delle sezioni di progetto e bilancio sociale (RF-6.2, RF-7.3), stati del flusso di approvazione (RT-3). Nessun passo modificato |
 | 0.4.2 | 27/09/2026 | 0.4 | Aggiunti i diagrammi di W1, W4 e W5, ripresi da `software.old/flussi-di-lavoro.md`. Aggiunto il passo 🔸 7 di W4 (cessazione o correzione come nuova voce collegata): senza, una voce archiviata non si poteva più aggiornare, nemmeno con la data di cessazione richiesta da RF-4.1 e RF-4.2. Matrice dei permessi e ciclo di rilascio del vecchio documento sono in `architettura.md` §5 e §8.2. Nessun requisito modificato: il nuovo passo è una deduzione 🔸 |
 | 0.4.3 | 27/09/2026 | 0.4 | Allineamento ad `architettura.md` §3: in W1 passo 6 l'accesso dell'ente si attiva con un link a scadenza invece dell'invio delle credenziali. Nessun requisito modificato |
 ---
 ## Stato
- **Fase corrente:** analisi dei requisiti, workflow v0.3.1.
+- **Fase corrente:** analisi dei requisiti, workflow v0.4.3.
- **Decisioni prese:** D1–D11 (`richiesta.md` §7), riportate nei passi.
+- **Decisioni prese:** D1–D13 (`richiesta.md` §7), riportate nei passi.
- **Prossimo passo:** confermare con il cliente i passi 🔸 (`domande-cliente.md` A4) e rispondere alle domande ⏳; poi aggiornare i passi coinvolti.
+- **Prossimo passo:** risposte del cliente alle domande ⏳; validazione dei passi 🔸 al collaudo.
Author	SHA1	Message	Date
davideandClaude Sonnet 5	b7374ffab5	Orienta B1.10 su Django e allinea versioni Davide conosce Python: architettura.md §6 documenta l'orientamento su Django (non ancora decisione formale) con le librerie da aggiungere per coda/pianificatore e notifiche in-app; domande- cliente.md e indice-documenti.md allineati. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-27 19:41:16 +02:00
davideandClaude Sonnet 5	2b223f0c1c	Riorganizza le spese per certezza e corregge un riferimento a D11 in architettura costi-ricorrenti.md: §4 diviso in spese legate a un requisito in attesa di risposta del cliente e spese facoltative, senza toccare cifre. architettura.md: tolta l'indicazione che D11 avesse deciso le ore di manutenzione dal secondo anno, mai decise. Riformulato in tono più formale il documento di domande per il cliente, non ancora inviato. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-27 19:25:42 +02:00
davideandClaude Sonnet 5	4441fa2cd1	Aggiunge architettura.md e blueprint.md, sostituisce la proposta CSV con le domande cliente Ricostruisce architettura e blueprint da software.old adattandoli al repository, verificati sulle fonti. Elimina la proposta CSV mai inviata e la sostituisce con invii/2026-09-27_domande-cliente_v0.4.md. Allinea versioni e registro modifiche di richiesta.md, workflow.md, domande-cliente.md e indice-documenti.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-27 19:13:30 +02:00
davideandClaude Sonnet 5	8c7ffb4feb	Riscrive costi-ricorrenti.md in forma lineare e allinea i documenti - costi-ricorrenti.md a v0.4.4: forma lineare con link alle fonti dei prezzi, firma in test verificata (era già stato portato a v0.4.3 con voci variabili a formula ed esempi per 30/200 enti) - Aggiunta invii/2026-09-27_costi_v0.4.md: versione semplice dei costi per il cliente (solo euro, formule), al posto del .docx precedente mai inviato - richiesta.md 0.4.3: RT-3 allineato a W4; legenda dei simboli spostata in indice-documenti.md - workflow.md 0.4.1: allineamento - domande-cliente.md 0.4.4: corrispondenza tra domande della proposta e codici Q spostata qui - indice-documenti.md: registrate tutte le modifiche sopra Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-27 16:59:30 +02:00
davideandClaude Sonnet 5	4e888ba890	Crea la proposta CSV per il cliente e allinea la documentazione - Aggiunta invii/2026-09-27_proposta_v0.4.csv: proposta con le stesse colonne dell'Excel del cliente [X], comprese le domande aperte, da inviare per validazione e raccolta di eventuali correzioni - domande-cliente.md portato a v0.4.3: tolte dalla proposta le domande su decorrenza del primo anno (Q23) e approvazione/modifiche (Q18), che restano aperte solo qui - richiesta.md, costi-ricorrenti.md, workflow.md: allineamento generale di riferimenti e coerenza tra i documenti - CLAUDE.md: aggiunta la cartella invii/ all'elenco dei documenti; chiarito che gli invii in qualsiasi formato si registrano in §1.3 di indice-documenti.md - indice-documenti.md: registrate tutte le modifiche sopra (§1.2, §1.3, §3) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-27 16:33:32 +02:00