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
1 parent 8c7ffb4feb
commit 4441fa2cd1
@@ -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. Unica scelta tecnica presa: database PostgreSQL con migrazioni (D12). Stack applicativo, hosting e fornitori non sono ancora scelti. 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
@@ -41,12 +41,14 @@ Consulente tecnico senior in architettura software, DevOps e preventivazione. Da
 | `workflow.md` | Processi del software passo per passo (W), con i riferimenti ai requisiti |
 | `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. la proposta in CSV); elenco in `indice-documenti.md` §1.3. Non si modificano: una versione nuova è un file nuovo |
+| `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.
@@ -68,6 +70,8 @@ Consulente tecnico senior in architettura software, DevOps e preventivazione. Da
 | Wn | Workflow | `workflow.md` |
 | 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` §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.
@@ -97,7 +101,7 @@ 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.
@@ -0,0 +1,272 @@
 # Architettura del software
 **Progetto:** Gestionale per enti del Terzo Settore
 **Documento:** `architettura.md`
 **Versione:** 0.4.3 · **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 🔸:** sui requisiti Laravel e Django si equivalgono; decide la **conoscenza di Davide**, perché nel controllo del codice conta più di qualunque differenza tecnica. A parità di conoscenza, Laravel ha un piccolo vantaggio: coda, pianificatore e notifiche con stato di lettura sono inclusi, quindi ci sono meno componenti da scegliere, aggiornare e consegnare.
 **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; ore di manutenzione (D11) |
 ---
 ## 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) |
 ---
 ## Stato
 - **Fase corrente:** analisi dei requisiti; architettura in bozza v0.4.3.
 - **Decisioni prese:** D12 (PostgreSQL, migrazioni, row-level security); firma simulata in sviluppo (`costi-ricorrenti.md`). Il resto è proposta 🔸.
 - **Prossimo passo:** Davide sceglie lo stack (B1.10) e conferma 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,34 +1,36 @@
 # Domande per il cliente
 **Progetto:** Gestionale per enti del Terzo Settore
 **Documento:** `domande-cliente.md`
-**Versione:** 0.4.4 · **Data:** 27/09/2026 · **Stato:** Bozza
+**Versione:** 0.4.6 · **Data:** 27/09/2026 · **Stato:** Bozza
 **Allineato a:** `richiesta.md` v0.4 · **Schema di versione:** vedi `indice-documenti.md`
-Al cliente arrivano le sezioni 1 e 2 tramite la proposta (`indice-documenti.md` §1.3). La sezione 3 è solo per Davide.
+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.
-**Criterio:** restano solo le domande la cui risposta sposta molto costi od ore e che può dare solo il cliente. Le altre sono ipotesi 🔸 (`richiesta.md` §7).
+**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).
 ---
 ## 1. Domande
-### 1.1 Nella proposta al cliente
+### 1.1 Nel documento per il cliente
-Colonna "N.": numero della domanda in `invii/2026-09-27_proposta_v0.4.csv`.
+Colonna "N.": numero della domanda in `invii/2026-09-27_domande-cliente_v0.4.md`.
 | # | N. | Domanda | Risposta |
 |---|---|---|---|
 | Q1 | 1 | Quanti enti pensate di gestire, oggi e tra 3 anni? | |
 | Q4 | 2 | Che firma serve per offerte, privacy, antiriciclaggio e libri sociali: semplice (codice via SMS), avanzata o qualificata? | |
-| Q9 | 3 | Per i libri sociali basta un archivio con data certa, o serve la conservazione digitale a norma? | |
+| 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 | 4 | Il software deve fare anche la fattura elettronica, o bastano i proforma? Usate già un programma di fatturazione? | |
 | Q10 | 5 | Gli estratti conto in PDF vanno letti in automatico o basta archiviarli? | |
 | 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 | 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? | |
 | 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) | |
 ### 1.2 Da trattare di persona o nel contratto
-Non sono nella proposta: si chiudono all'incontro o si scrivono nel contratto.
+Non sono nel documento per il cliente: si chiudono all'incontro o si scrivono nel contratto.
 | # | Domanda | Risposta |
 |---|---|---|
@@ -39,8 +41,9 @@ Non sono nella proposta: si chiudono all'incontro o si scrivono nel contratto.
 ## 2. Da comunicare al cliente
-Sono nella proposta, sezione GENERALE:
+Sono nel documento per il cliente, §2:
- decisioni da comunicare: D8 (RT-14; importazione da Excel quotabile a parte), D9 (RT-12, RT-13), D10–D11; validazione delle ipotesi 🔸 al collaudo (`richiesta.md` §7);
+- decisioni da comunicare: D2 (RT-1), D8 (RT-14; importazione da Excel quotabile a parte), D9 (RT-12, RT-13), D10–D11;
 - 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.
 ---
@@ -75,8 +78,11 @@ Sono nella proposta, sezione GENERALE:
 | B1.4 | Fornitori di firma, marca, conservazione | Q4, Q9 | Fornitori qualificati |
 | B1.5 | Fattura elettronica | Q5 | Integrazione, non sviluppo da zero |
 | B1.9 | Ore per il passaggio dei servizi | Q23 | Da stimare nel preventivo |
 | B1.10 | Linguaggio e framework dell'applicazione | Conoscenza di Davide; RT-15 | Laravel o Django, equivalenti sui requisiti: `architettura.md` §6 |
 | B1.11 | Guida d'uso e formazione degli utenti | — | Nessun requisito nelle fonti; se offerte, vanno nel preventivo (`blueprint.md` §6) |
 | B1.12 | Correzione dei difetti nel primo anno (garanzia) | ⚖️ C10 | Da distinguere dalla manutenzione del secondo anno (D11), nel preventivo o nel contratto |
-**Già orientate (da motivare 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).
+**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).
 ### Da chiedere più avanti
 Q14 (sezioni del bilancio sociale) e Q15 (valore delle ore di volontariato): prima di sviluppare la fase 2.
@@ -87,6 +93,7 @@ Q14 (sezioni del bilancio sociale) e Q15 (valore delle ore di volontariato): pri
 - **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.
@@ -107,10 +114,12 @@ Q14 (sezioni del bilancio sociale) e Q15 (valore delle ore di volontariato): pri
 | 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 |
 ---
 ## Stato
 - **Fase corrente:** analisi dei requisiti, domande pronte per il cliente.
 - **Decisioni prese:** D1–D13 (`richiesta.md` §7).
- **Prossimo passo:** commercialista su C12; invio della proposta (7 domande); Q23 e Q18 all'incontro o nel contratto.
+- **Prossimo passo:** commercialista su C12; invio del documento delle domande (9 domande); Q23 e Q18 all'incontro o nel contratto.
@@ -25,10 +25,12 @@ 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.4.3** | 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.4.1** | Bozza | `richiesta.md` v0.4 |
+| `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 essenziali per il cliente (Q), cose da comunicare, verifiche con legale e commercialista (C), scelte in sospeso (B), rischi | **0.4.4** | Bozza | `richiesta.md` v0.4 |
+| `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.6** | Bozza | `richiesta.md` v0.4 |
 | `costi-ricorrenti.md` | Costi ricorrenti di sviluppo, test e produzione: prezzi con fonte, formule delle voci variabili, scenari, effetti economici delle decisioni | **0.4.4** | 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.3** | 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 |
@@ -38,7 +40,7 @@ Copie fisse di ciò che viene preparato o inviato al cliente (cartella `invii/`)
 | File | Contenuto | Basato su | Stato |
 |---|---|---|---|
-| `invii/2026-09-27_proposta_v0.4.csv` | Proposta con le stesse colonne dell'Excel del cliente, più "Osservazioni"; 23 righe di funzioni e 7 domande (corrispondenza con i codici Q in `domande-cliente.md` §1.1). Versione rivista da Davide; Q23 e Q18 non incluse, da trattare direttamente con il cliente | `richiesta.md` v0.4.2, `workflow.md` v0.4, `domande-cliente.md` v0.4.2 (§1 e §2) | Preparato, non ancora inviato |
+| `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.
@@ -52,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)
 ```
 ---
@@ -76,7 +81,7 @@ fonti/AAAA-MM-GG/ (docx, xlsx del cliente)
 ### 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
@@ -117,3 +122,8 @@ La versione si legge nell'intestazione e in questo indice. Quando un documento v
 | 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) |
@@ -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:** dove dicono cose diverse vale l'Excel; ciò che compare in uno solo dei due è incluso.
 - **Dati separati:** ogni ente vede solo i propri dati; lo studio vede quelli di tutti gli enti.
 - **Utilizzo:** software web da usare dal computer, senza app per smartphone; dati conservati nell'Unione Europea e trattati nel rispetto del GDPR.
 - **Dati esistenti:** il software parte vuoto; soci e volontari già presenti si inseriscono a mano. Un'importazione da Excel si può quotare a parte.
 - **Servizi (server, email, firma, backup):** il primo anno sono a mio carico e compresi nel preventivo; dal secondo anno passano a vostro nome, con un contratto di manutenzione.
 ### 2.2 Funzioni che ho completato io
 Nei documenti non sono descritte nel dettaglio; le ho impostate così e le verificherete durante il collaudo. Se qualcosa non va, ditemelo anche prima.
 | 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
 Servono per sviluppare le funzioni indicate. Vi chiedo di indicare una data di consegna: la inseriremo nel contratto, perché un ritardo sposta i tempi di consegna.
 | 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,31 +0,0 @@
 MODULI;FUNZIONI;CONTENUTI;OPERATORE;NOTE;OSSERVAZIONI
 GESTIONE CLIENTE;Offerte;"Servizi singoli o a pacchetto scelti dal catalogo; modalità di pagamento e scadenze";interno;;
 ;Firma;Offerta, privacy e antiriciclaggio firmate in digitale dall'ente;esterno;domanda 2;
 ;Scadenze e proforma;Scadenziario automatico, avviso allo studio, proforma alle scadenze, registrazione dei pagamenti;interno;domanda 4;
 ;Accesso degli enti;"Lo studio crea l'accesso per l'ente; un'offerta rifiutata o non firmata si chiude";interno;proposta;
 ANAGRAFICA ENTI;Dati dell'ente;Denominazione, sede, codice fiscale, partita IVA, data di costituzione, iscrizione RUNTS (numero, data, sezione), qualifica, attività art. 5 e art. 6 CTS, raccolte fondi;interno;;
 ;Numero soci e volontari;Inseriti a mano, con accanto il conteggio automatico;interno;proposta;
 ANAGRAFICA PERSONE;Persone dell'ente;Soci, aderenti, tesserati, volontari, volontari occasionali, dipendenti, collaboratori, sostenitori, partecipanti: dati anagrafici e contatti;esterno;Una sola scheda per persona, anche con più ruoli: proposta;
 LIBRI SOCIALI;Libro soci;Data di ammissione, dati anagrafici, contatti, data di cessazione, note, firma dell'operatore;esterno;;
 ;Registro volontari;Data di inizio, dati anagrafici, contatti, data di fine, note, firma dell'operatore;esterno;;
 ;Verbali;Assemblea dei soci e organo di amministrazione;esterno;;
 ;Controllo e archivio;"Lo studio controlla, può rimandare all'ente per correzioni, approva; marca temporale e stampa";entrambi;domanda 3;
 CONTABILITÀ;Caricamento documenti;"Estratti conto (Excel o PDF), prima nota cassa, rendiconti delle raccolte fondi; avvisi alle scadenze e solleciti";esterno;domanda 5;
 ;Imputazione;Ogni movimento assegnato a una voce del Modello D;interno;;
 ;Rendiconto e relazione;Modello D automatico e relazione illustrativa guidata, approvati dallo studio;entrambi;;
 PROGETTAZIONE;Progetti per bandi;Contesto, bisogni, idea, obiettivi, attività, risorse, cronoprogramma, costi, piano economico-finanziario;entrambi;Schema e formulari: domanda 6. Divisione del lavoro: domanda 7;
 CIRCOLARI;Circolari;"Scadenze amministrative, contabili e fiscali; via email e nel software, con conferma di lettura; a tutti gli enti o a gruppi";interno;;
 BILANCIO SOCIALE;Bilancio sociale;"Lettera del presidente, dati standard, identità, stakeholder, utenti, obiettivi e attività, situazione economica, relazione dell'organo di controllo; riusa i dati già presenti";entrambi;;
 VALUTAZIONE VOLONTARIATO;Time sheet;Ore di volontari e dipendenti per attività e ruolo, con valore economico;interno;;
 GENERALE;Accesso;"Ogni ente vede solo i propri dati; lo studio vede tutto";;;
 ;Utilizzo;"Software web per computer; dati in Unione Europea; conforme al GDPR";;;
 ;Dati esistenti;Soci e volontari già presenti si inseriscono a mano;;Importazione da Excel quotabile a parte;
 ;Servizi;"Il primo anno a mio carico; dal secondo anno a vostro nome, con contratto di manutenzione";;;
 ;Materiali da voi;Schema dei progetti, modelli di verbale e circolare, un estratto conto per banca, tariffe orarie del volontariato;;Con data di consegna;
 DOMANDE;1;Quanti enti pensate di gestire, oggi e tra 3 anni?;;;
 ;2;Che firma serve: semplice (codice via SMS), avanzata o qualificata?;;;
 ;3;Per i libri sociali basta un archivio con data certa, o serve la conservazione digitale a norma?;;;
 ;4;Serve 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, e per quando? In che formato va esportato? L'adattamento ai formulari lo fate voi a mano?;;;
 ;7;Nei progetti e nel bilancio sociale: l'ente scrive e voi rivedete, ognuno compila le sue parti, o lavorate insieme sullo stesso documento?;;;
@@ -1,14 +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.4.3 · **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" (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. Contenuto degli altri documenti e simboli: `indice-documenti.md` §1.2 e §2.5.
+**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.
 ---
@@ -32,19 +32,19 @@
 ## 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: 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 |
+| 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 | ⏳ 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 (Q15 prima della fase 2) |
 **Fase 1:** M1, M2, M3, M4, M5, M6, M8 · **Fase 2:** M7, M9.
@@ -84,8 +84,8 @@ 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 | |
@@ -93,7 +93,7 @@ Scheda completa di ciascun ente cliente, compilata dallo studio.
 | 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; 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.
@@ -123,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 |
@@ -235,7 +235,7 @@ 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 | ✅ D13: inclusi tutti |
 | 4 | Categorie di persone | 7 categorie | 6 categorie, in parte diverse | ✅ D13: incluse tutte |
@@ -258,7 +258,7 @@ Decisioni indicate da Davide: D1–D9 il 25/09/2026, D10–D13 il 27/09/2026. Va
 |---|---|---|---|
 | 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 |
@@ -286,10 +286,12 @@ Decisioni indicate da Davide: D1–D9 il 25/09/2026, D10–D13 il 27/09/2026. Va
 | 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.4.3.
+- **Fase corrente:** analisi dei requisiti, bozza v0.4.5.
 - **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,7 +1,7 @@
 # Workflow del software
 **Progetto:** Gestionale per enti del Terzo Settore
 **Documento:** `workflow.md`
-**Versione:** 0.4.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.4 · **Schema di versione:** vedi `indice-documenti.md`
 ---
@@ -64,10 +64,21 @@ flowchart LR
 | 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)
@@ -111,9 +122,21 @@ 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:** quelli del flusso di approvazione comune (RT-3), riusato in W5, 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
 ```
 ---
 ## 6. W5: Ciclo contabile (M5)
@@ -132,6 +155,17 @@ flowchart LR
 | 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.
@@ -218,10 +252,12 @@ flowchart LR
 | 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.4.1.
+- **Fase corrente:** analisi dei requisiti, workflow v0.4.3.
 - **Decisioni prese:** D1–D13 (`richiesta.md` §7), riportate nei passi.
 - **Prossimo passo:** risposte del cliente alle domande ⏳; validazione dei passi 🔸 al collaudo.