davideandClaude Sonnet 5
b7374ffab5
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>
134 lines
13 KiB
Markdown
134 lines
13 KiB
Markdown
# Indice dei documenti di progetto
|
||
**Progetto:** Gestionale per enti del Terzo Settore
|
||
**Documento:** `indice-documenti.md` · **Aggiornato il:** 27/09/2026
|
||
|
||
Questo indice è il punto unico in cui si vede **quale versione è in vigore** per ogni documento e **come si versionano**. Si aggiorna ogni volta che un documento cambia versione.
|
||
|
||
---
|
||
|
||
## 1. Documenti in vigore
|
||
|
||
### 1.1 Documenti del cliente (fonti)
|
||
|
||
Le fonti stanno nella cartella `fonti/`, con una sottocartella per ogni consegna, nominata con la data di ricezione. I file in `fonti/` non si modificano mai.
|
||
|
||
| Consegna | File | Contenuto | Note |
|
||
|---|---|---|---|
|
||
| `fonti/2026-09-25/` | `funzioni software.docx` | Funzioni richieste, divise in base e aggiuntive ([D]) | ⚠️ **Originale da copiare in cartella** (Davide). Nel frattempo c'è `funzioni software - testo estratto.md`, trascrizione senza modifiche |
|
||
| `fonti/2026-09-25/` | `Software.xlsx` | Tabella Moduli / Funzioni / Contenuti / Operatore / Note ([X]) | Originale. SHA-256: `419b4d48…fb63cb9` |
|
||
|
||
Il cliente non indica versioni: ogni consegna si identifica con la data di ricezione. Se il cliente manda una nuova versione, si crea una nuova sottocartella **senza toccare le precedenti**, si aggiunge una riga qui e si aggiorna `richiesta.md`.
|
||
|
||
### 1.2 Documenti di progetto
|
||
|
||
Ogni informazione sta in **un solo documento**; gli altri la richiamano con il suo codice.
|
||
|
||
| 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.5** | Bozza | Fonti del 25/09/2026 |
|
||
| `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.7** | Bozza | `richiesta.md` v0.4 |
|
||
| `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:**
|
||
|
||
```
|
||
fonti/AAAA-MM-GG/ (docx, xlsx del cliente)
|
||
↓
|
||
richiesta.md ← documento base
|
||
↓
|
||
├── workflow.md
|
||
├── domande-cliente.md
|
||
├── costi-ricorrenti.md
|
||
└── architettura.md
|
||
↓
|
||
blueprint.md (usa anche workflow, domande e costi)
|
||
```
|
||
|
||
---
|
||
|
||
## 2. Schema di versione
|
||
|
||
### 2.1 Numero di versione: `X.Y.Z`
|
||
|
||
| Parte | Significato | Quando cambia |
|
||
|---|---|---|
|
||
| **X** | Stato di validazione | **0** = bozza, non ancora approvata dal cliente · **1** = approvata dal cliente (base per il preventivo) · **2, 3…** = nuova versione approvata dopo una modifica dei requisiti a progetto avviato |
|
||
| **Y** | Revisione dei contenuti | Quando cambia **cosa deve fare il software**: nuove risposte del cliente, nuove decisioni, requisiti aggiunti o tolti |
|
||
| **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.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.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, 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
|
||
|
||
1. Aggiornare il contenuto del documento.
|
||
2. Aggiornare l'intestazione: versione, data, stato.
|
||
3. Aggiungere una riga al **registro delle modifiche** in fondo al documento: cosa è cambiato e perché.
|
||
4. Se è cambiato `richiesta.md`, aggiornare i documenti derivati e allinearne la versione.
|
||
5. Aggiornare la tabella del §1.2 di questo indice.
|
||
|
||
### 2.4 Nomi dei file
|
||
|
||
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-27_domande-cliente_v0.4.md`; solo §1 e §2, mai il §3), per sapere sempre cosa ha ricevuto il cliente.
|
||
|
||
---
|
||
|
||
## 3. Registro delle modifiche dell'indice
|
||
|
||
| Data | Modifica |
|
||
|---|---|
|
||
| 25/09/2026 | Creazione dell'indice e dello schema di versione; tutti i documenti di progetto portati a v0.2 |
|
||
| 25/09/2026 | Aggiunto `CLAUDE.md` |
|
||
| 25/09/2026 | `CLAUDE.md` aggiornato da Davide: posizione delle fonti [D] e [X], codici Bn.m, simbolo ⚖️, struttura standard dei documenti, obbligo di versione a ogni modifica, procedura per gli invii al cliente; tolta la sezione "Da non fare" |
|
||
| 25/09/2026 | Creata la cartella `fonti/2026-09-25/` con le fonti del cliente; aggiornati §1.1 e schema delle dipendenze; aggiornato `CLAUDE.md` (percorsi delle fonti e regole della cartella `fonti/`) |
|
||
| 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 |
|