# Conventions de rédaction technique

Ce fichier capitalise les **conventions de documentation et rédaction technique** validées
sur les projets Lead_tech : tone of voice, structure des docs, formats récurrents.

Objectif : produire une documentation cohérente d'un projet à l'autre,
réduire le temps de rédaction et de relecture.

Dernière mise à jour : 2026-03-09

---

## Index

- [Langue par type de document](#convention-langue-par-type-de-document)
- [File List story — exhaustivité obligatoire](#convention-file-list-story)

---

## Règle d'or

Une convention n'a sa place ici que si elle a été appliquée et validée sur au moins un projet réel.
Pas de "bonne pratique" théorique.

---

## Périmètre couvert

- Tone of voice par type de doc (API, user-facing, interne)
- Structure standard des fichiers README, CLAUDE.md, ADR
- Format des changelogs et release notes
- Conventions de nommage (fichiers, titres, sections)
- Règles de maintenance de la documentation (quand mettre à jour, quoi archiver)

---

## Format standard d'une convention

## Convention : <Nom clair>

- Scope : (type de document concerné)
- Règle : …
- Exemple : …
- Contre-exemple : …
- Validé le : DD-MM-YYYY
- Contexte projet : …

---

## Conventions actives

<a id="convention-langue-par-type-de-document"></a>
### Convention : Langue par type de document

- Scope : tous les fichiers du repo Lead_tech et des projets
- Règle : français pour toute la documentation, commentaires de code, messages de commit. Anglais pour les identifiants de code (variables, fonctions, types).
- Validé le : 2026-03-08
- Contexte projet : Lead_tech (convention globale)

---

<a id="convention-file-list-story"></a>
### Convention : File List story — exhaustivité obligatoire

- Scope : section "File List" des story files BMAD (Dev Agent Record)
- Règle : inclure **tous** les fichiers créés ou modifiés pendant la story — migrations, modules infra, fichiers contracts, fichiers de config. Un reviewer ne doit pas avoir à faire `git status` pour reconstituer le périmètre.
- Règle complémentaire : les fichiers créés en avance de phase (scope d'une story future) doivent être annotés : `— créé en avance (scope story X.Y)`
- Vérification recommandée : cross-checker via `git status --porcelain` avant de passer la story en review
- Contre-exemple : story 2.3 app-alexandrie — 13 fichiers manquants (migrations, modules Redis, services entitlements, error codes contracts)
- Validé le : 09-03-2026
- Contexte projet : app-alexandrie

---