ff
This commit is contained in:
@@ -0,0 +1,83 @@
|
||||
# DECISIONS — Registro delle decisioni architetturali (ADR)
|
||||
|
||||
Ultimo aggiornamento: **{{DATA}}** · Progetto: **{{PROGETTO}}**
|
||||
|
||||
Ogni decisione strutturale del progetto è registrata qui con un identificativo `D-xxx` immutabile.
|
||||
Le decisioni si **superano**, non si cancellano: una decisione sbagliata resta a registro con stato
|
||||
*Superata da D-yyy*, così la storia del progetto resta leggibile.
|
||||
|
||||
**Stati:** `Proposta` · `Accettata` · `Superata da D-xxx` · `Respinta`
|
||||
|
||||
**Formato:** Contesto → Decisione → Alternative valutate → Conseguenze.
|
||||
|
||||
---
|
||||
|
||||
## Indice
|
||||
|
||||
| ID | Titolo | Stato | Data |
|
||||
|---|---|---|---|
|
||||
| [D-001](#d-001--stack-tecnologico) | Stack tecnologico | Proposta | {{DATA}} |
|
||||
| [D-002](#d-002--sviluppo-spec-driven-vincolante) | Sviluppo spec-driven vincolante | Accettata | {{DATA}} |
|
||||
| [D-003](#d-003--la-documentazione-vive-nel-repository) | La documentazione vive nel repository | Accettata | {{DATA}} |
|
||||
|
||||
---
|
||||
|
||||
## D-001 — Stack tecnologico
|
||||
|
||||
**Stato:** Proposta · {{DATA}}
|
||||
|
||||
### Contesto
|
||||
<!-- DA COMPILARE: vincoli del committente, competenze, sistemi esistenti con cui integrarsi. -->
|
||||
|
||||
### Decisione
|
||||
<!-- DA COMPILARE: linguaggi, framework, database, code, storage, deploy. -->
|
||||
|
||||
### Alternative valutate
|
||||
- <!-- DA COMPILARE: alternativa — perché scartata. -->
|
||||
|
||||
### Conseguenze
|
||||
- <!-- DA COMPILARE -->
|
||||
|
||||
---
|
||||
|
||||
## D-002 — Sviluppo spec-driven vincolante
|
||||
|
||||
**Stato:** Accettata · {{DATA}}
|
||||
|
||||
### Contesto
|
||||
Le regole di business scritte solo nel codice emergono dal debugging invece che dalla
|
||||
specifica, e si scoprono quando un difetto le rivela.
|
||||
|
||||
### Decisione
|
||||
Nessuna implementazione senza una `SPEC-xxx` in stato *Approvata*. Ogni spec contiene: contesto,
|
||||
requisiti coperti (`REQ-xxx`), contratto API, modello dati, regole, casi di errore, criteri di
|
||||
accettazione, task derivati (`T-xxx`). `07-quality/TRACEABILITY.md` mantiene la matrice
|
||||
REQ → SPEC → T → test e non deve avere righe vuote. Il contratto API (`04-api/openapi.yaml`) è
|
||||
la fonte di verità e si scrive prima del codice.
|
||||
|
||||
### Alternative valutate
|
||||
- **Documentazione a valle del codice.** Produce documenti veri ma tardivi; le regole restano
|
||||
scoperte finché un bug non le rivela.
|
||||
|
||||
### Conseguenze
|
||||
- La fase di documentazione precede quella di codice; il codice inizia più tardi e procede più dritto.
|
||||
- Una spec approvata si modifica solo con una nuova `D-xxx` o una revisione tracciata.
|
||||
|
||||
---
|
||||
|
||||
## D-003 — La documentazione vive nel repository
|
||||
|
||||
**Stato:** Accettata · {{DATA}}
|
||||
|
||||
### Contesto
|
||||
Documentazione e codice divergono quando vivono in luoghi diversi.
|
||||
|
||||
### Decisione
|
||||
`docs/` sta nel repository del codice e si aggiorna **nella stessa modifica** del codice che la
|
||||
riguarda.
|
||||
|
||||
### Alternative valutate
|
||||
- **Wiki esterno.** Più comodo da modificare, ma non versionato con il codice.
|
||||
|
||||
### Conseguenze
|
||||
- Una revisione del codice è anche revisione della documentazione.
|
||||
Reference in New Issue
Block a user