# Workflow — Risques & vigilance : Story tracking

> Extrait de la base de connaissance Lead_tech. Voir `knowledge/workflow/risques/README.md` pour l'index complet.

---

<a id="risque-story-completed-taches-echec"></a>
## Story "completed" avec tâches ❌ auto-déclarées

### Risques

- Un agent sette `Status: completed` alors que son propre Dev Agent Record liste des items ❌ non implémentés
- Le store mobile, service ou tests peuvent être déclarés manquants par l'agent lui-même mais la story semble terminée

### Symptômes

- Dev Agent Record contient `❌ store mobile non implémenté` mais `Status: completed`
- Code review découvre des ACs non satisfaits

### Bonnes pratiques / mitigations

- Avant de setter `Status: completed`, vérifier que le Dev Agent Record ne contient aucun ❌
- En cas de doute ou d'item manquant, setter `Status: review` pour déclencher la code review
- **Règle** : `Status: completed` = zéro ❌ auto-déclaré dans le Dev Agent Record

- Contexte technique : BMAD / workflow agent — app-alexandrie 20-03-2026

---

<a id="risque-story-done-file-list-vide"></a>
## Story "done" sans aucun fichier source dans la File List

### Risques

- Un agent peut halluciner la completion d'une story en produisant une note générique sans écrire de code
- La File List ne contient que des fichiers `_bmad-output/` mais aucun `src/`, `prisma/`, `tests/`

### Symptômes

- Completion note générique du type "Ultimate context engine analysis completed"
- File List réduite à 2 fichiers meta (story file, sprint-status)
- `git log --follow src/` ne montre aucun commit lié à la story

### Bonnes pratiques / mitigations

- Lors d'une code review, si la File List ne contient aucun fichier source : traiter comme non implémentée
- Vérifier avec `git log --follow src/` avant d'accepter le `Status: done`
- Ne pas faire confiance au status `done` sans preuve dans le code

- Contexte technique : BMAD / agent Codex — app-template-resto 21-03-2026

---

<a id="risque-file-list-hors-perimetre"></a>
## Story validée avec changements hors périmètre non documentés

### Risques

- Le reviewer valide un faux scope ou rejette à tort une story correcte.
- Des changements source non tracés (working tree dirty) peuvent masquer une implémentation partielle ou des effets de bord.

### Symptômes

- Tâches `[x]` et File List propre, mais `git status` montre des fichiers modifiés hors story
- Aucun bloc "hors périmètre" dans le Dev Agent Record alors que des fichiers non liés ont été touchés

### Bonnes pratiques / mitigations

- Si des changements hors story sont présents dans le working tree, documenter un bloc **"hors périmètre"** explicite dans le Dev Agent Record (liste courte + justification).
- Ne marquer `done` qu'après clarification de périmètre.
- **Règle** : le reviewer croise systématiquement `git diff --name-only` avec la File List avant d'accepter.

- Contexte technique : BMAD / workflow agent — 30-03-2026

---

<a id="risque-file-list-approximative"></a>
## File List approximative — chemins faux ou fichiers source absents

### Risques

- Validation d'une implémentation avec traçabilité mensongère.
- Chemins fictifs dans la File List non détectés si le reviewer ne croise pas avec `git`.

### Symptômes

- File List courte ou générique alors que le diff réel touche de nombreux fichiers source
- Fichier listé avec un chemin qui n'existe pas dans le repo

### Bonnes pratiques / mitigations

- **Règle review** : comparer la File List du Dev Agent Record au `git diff --name-only` réel.
- Tout fichier source modifié absent de la File List → signaler en **MEDIUM**.
- Tout fichier listé avec un chemin inexistant en git → signaler en **HIGH**.

- Contexte technique : BMAD / workflow agent — app-template-resto 31-03-2026