# Exemple d'evidence note : bugfix de filtre

Cet exemple reprend le bug volontairement simple de l'article : `GET /api/orders?status=CLOSED` retourne aussi des commandes `OPEN` ou `PENDING` lorsque `search` est absent.

## Demande initiale

Reproduire le bug avec un test de régression, corriger la cause de façon minimale, puis valider la correction.

## Résumé

Le filtre `status` est maintenant appliqué indépendamment du paramètre `search`.
Le comportement de recherche texte reste inchangé.
Un test de régression couvre le cas `status=CLOSED` sans recherche texte.

## Scope réalisé

- Correction locale de la construction du filtre de recherche commandes.
- Ajout d'un test ciblé sur `status` sans `search`.
- Aucun changement du contrat public de l'API.

## Fichiers modifiés

- `src/orders/order-query.ts`
- `tests/orders/order-query.test.ts`

## Ce qui a changé

- Le filtre `status` est appliqué avant la construction de la condition de recherche texte.
- La condition `search` continue à construire le `OR` sur `reference` et `customerName`.
- Le test vérifie que toutes les commandes retournées ont le statut `CLOSED`.

## Validations exécutées

| Commande | Résultat | Commentaire |
| --- | --- | --- |
| `npm test -- tests/orders/order-query.test.ts -t "applies the status filter when search is empty"` | Passé | Test de régression ciblé. |
| `npm test -- tests/orders/order-query.test.ts` | Passé | Suite du module commandes. |
| `npm run lint -- src/orders/order-query.ts tests/orders/order-query.test.ts` | Passé | Lint sur les fichiers modifiés. |

## Validations non exécutées

| Commande | Raison | Vérification alternative |
| --- | --- | --- |
| `npm test` | Suite complète trop longue dans l'environnement local. | Lancer la suite complète en CI avant merge. |

## Non-goals vérifiés

- Pas de changement du contrat `GET /api/orders`.
- Pas de changement des statuts existants.
- Pas de changement de pagination.
- Pas de changement du comportement de recherche texte.
- Pas de nouvelle dépendance.

## Comportements inchangés

- `search` continue à filtrer sur `reference` et `customerName`.
- Les résultats valides avec `status` et `search` combinés restent supportés.
- Les appels sans filtre continuent à retourner la liste attendue.

## Risques et limites

- La correction ne couvre pas les autres filtres éventuels comme `customerId`, `dateFrom` ou `dateTo`.
- La validation E2E de la route HTTP complète reste à confirmer si elle existe dans le projet.

## Points d'attention pour la review

- Vérifier que l'ordre d'application de `status` et `search` correspond au comportement attendu.
- Vérifier que le test utilise des données représentatives.
- Vérifier que le même bug ne se répète pas sur d'autres filtres.

## Décision proposée

- [x] Prêt à relire
- [ ] Prêt à merger après review
- [ ] Bloqué par une question produit
- [ ] Bloqué par une question technique