- Spezza il registro delle decisioni in docs/decisions/DD-XXX.md, con indice - Ripulisce DATABASE.md dalla storia delle migration e aggiunge la sezione Lettura - Riduce PROJECT_STATE.md a una pagina; la procedura di allestimento passa in OPERATIONS.md - Aggiunge OPERATIONS.md, GLOSSARIO.md, trappole note e checklist in ARCHITECTURE.md - Sintetizza la copertura test di badge.md e documenta docs/archive - Allinea AGENTS.md, README.md e la regola Cursor (tolto l'obbligo di develop, in contrasto con DD-019) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
25 lines
1010 B
Markdown
25 lines
1010 B
Markdown
# DD-002 — Sviluppo document-first
|
||
|
||
**Data:** agosto 2026
|
||
**Stato:** Accettata
|
||
|
||
**Contesto**
|
||
Con più persone (e assistenti AI) che lavorano sul codice, serviva un modo per evitare funzionalità “inventate” al volo e incoerenze tra moduli.
|
||
|
||
**Decisione**
|
||
Ogni nuova funzionalità significativa viene prima **progettata e documentata** in `docs/modules/`, poi implementata. Il flusso ufficiale è: idea → progettazione → documentazione → database → codice → test → release.
|
||
|
||
**Alternative scartate**
|
||
|
||
- Documentare solo a posteriori → troppo spesso incompleto o assente.
|
||
- Affidarsi solo al codice come documentazione → illeggibile per chi non programma.
|
||
|
||
**Conseguenze**
|
||
|
||
- Rallenta leggermente l’avvio di nuove feature, ma riduce rework e discussioni infinite.
|
||
- I moduli preesistenti vanno retro-documentati quando possibile.
|
||
- Nessuna feature non documentata entra in produzione.
|
||
|
||
**Riesame**
|
||
Se il team diventa molto piccolo e la documentazione smette di essere consultata.
|