Bug UX rapporté par Arthur : quand on crée une facture pour un nouveau
client via le combobox du dialog "+ Saisir" (option "Créer le client
« X »"), aucun champ email n'apparaissait. Au submit, l'API renvoyait
422 client_email_required mais le toast affiché était générique
("Création impossible. Vérifiez les champs.") sans guidance sur le
champ manquant. L'utilisateur se retrouvait coincé sans savoir
qu'il devait quitter le dialog et créer le client d'abord via /clients.
Friction quotidienne, jamais visible en démo (où on sélectionne un
client existant).
Fix :
- Nouveau champ `clientEmail` (string, default "") dans FormValues
- Validator zod email + max 254 char
- Render conditionnel via form.Subscribe : visible UNIQUEMENT quand
`clientId === null && clientName.trim().length >= 2` (= création
à la volée). Disparait dès que l'user sélectionne un client
existant ou vide le combobox.
- Validation finale : requis seulement si clientId null
- mutationFn envoie `clientEmail || null` au backend uniquement en
mode création à la volée (pour client existant, l'email est déjà
en DB)
TDD : le test E2E "client inconnu — fournit l'email" a été écrit AVANT
le fix, échouait sur `getByLabel(/email du client/i) not found` (champ
inexistant), passe maintenant en 3.9 s. Empêche la régression future.
Le test vérifie aussi la chaîne complète :
- Facture créée + apparaît dans /factures
- Client créé en même temps + apparaît dans /clients avec son email
visible
État après ce commit : 27/27 tests Playwright verts.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Étend la suite Playwright avec 14 nouveaux scénarios couvrant les
surfaces critiques que tout user touche au quotidien.
Auth (7 tests) — auth.spec.ts :
- Signup : email invalide (HTML5), email déjà pris (422 → toast)
- Login : happy path après signup, mauvais password (401), email
inconnu (401)
- Protection des routes : / et /factures redirigent vers /login
sans session
Clients (5 tests) — clients.spec.ts :
- Create via dialog : remplir Nom + Email du contact → apparaît
dans la liste, compteur "1 fiche"
- Refuse email manquant (422, dialog reste ouvert)
- 2 clients distincts → compteur "2 fiches"
- Duplicate par nom case-insensitive → liste reste à 1 fiche
- Recherche ILIKE par nom → filtre côté liste
Factures (2 tests) — factures.spec.ts :
- Saisie manuelle complète : créer client puis facture via le
dialog (combobox client async + numéro + montant + Radix Select
plan) → apparaît dans /factures
- Empty state visible si aucune facture
Total Playwright après cette PR : 20 scénarios verts en 38 s.
Stratégie : les edge cases déjà couverts par les couches inférieures
(unit, functional japa, vitest) ne sont PAS re-testés en E2E pour
éviter la duplication. Le E2E garde son rôle : happy path UI + edge
cases produit qui n'apparaissent qu'au niveau navigation/forms.
Prochaines PRs prévues :
- PR 2 : OCR upload + Plans + Relances + Mailpit (mailing)
- PR 3 : Billing complet (trial→active/past_due/cancel) + Dashboard
KPIs + Settings
- PR 4 : Blog + edge cases globaux + coverage report c8
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
