docs(conventions): impose une couverture de tests pour chaque ajout (#61)

* docs(conventions): impose une couverture de tests pour chaque ajout

Trois nouvelles règles dans "## Tests" :
- ajout front autonome (components/ui/*) -> Cypress mode composant
- ajout front non autonome (dépend de son layout/page) -> Cypress
  mode layout, spec .cy.ts classique dans cypress/e2e/
- nouvelle fonctionnalité front (parcours utilisateur) -> Cypress e2e,
  scénario Gherkin "En tant que... je veux..." (s'ajoute au test
  layout, ne le remplace pas)
- ajout back testable -> Mocha + Chai dans apps/api/test/

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* claude.md

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

CLAUDE.md

@@ -0,0 +1,3 @@
+# Instructions du projet
+
+Avant toute action de génération de code, lis attentivement le fichier `specs\dev-conventions.md` pour prendre connaissance de l'ensemble des normes de développement à appliquer impérativement

specs/dev-conventions.md

@@ -206,6 +206,35 @@ directement à l'utilisateur).
 
 ## Tests
 
+### Couverture obligatoire pour tout ajout
+
+- **Ajout front autonome** (un composant réutilisable, sans routeur ni
+  backend — `components/ui/*`) : test Cypress en **mode composant**
+  (`cypress/component/*.cy.tsx`, voir `CheckboxOption.cy.tsx`/
+  `RadioOption.cy.tsx`) — monte le composant seul, sans app autour.
+- **Ajout front non autonome** (n'a de sens que dans son contexte de
+  page/layout — un élément de sidebar, une section d'une page existante) :
+  test Cypress en **mode layout**, un spec `.cy.ts` classique dans
+  `cypress/e2e/` (voir `layout.cy.ts`, `sidebar.cy.ts`,
+  `planning-page.cy.ts`) — pas de scénario Gherkin, juste la page routée
+  normalement.
+- **Toute nouvelle fonctionnalité front** (un vrai parcours utilisateur, pas
+  juste un composant/élément isolé) : test Cypress **e2e**, un scénario
+  Gherkin ("En tant que... je veux...") dans un `.feature` + ses définitions
+  d'étapes, en réutilisant `cypress/support/step_definitions/
+  common.steps.ts` quand c'est possible (voir `planning.feature`,
+  `recipe-sources.feature`). S'ajoute au test "mode layout" ci-dessus, ne le
+  remplace pas — une fonctionnalité a généralement les deux : le layout qui
+  l'affiche, et le parcours qui l'utilise.
+- **Tout ajout back testable** (logique pure, endpoint, service — tout ce
+  qui n'est pas du pur câblage/de la config) : test Mocha + Chai dans
+  `apps/api/test/`, même convention que le reste de la suite (voir
+  ci-dessous). "Testable" exclut les routes déjà couvertes par les tests
+  d'intégration du module (pas de doublon), pas la logique métier
+  elle-même.
+
+### Conventions générales
+
 - **`apps/api`** — Mocha + Chai, contre une vraie base Postgres isolée
   (`.env.test`, jamais la même base que `pnpm dev:api`), pas de mocks de la
   base ou des services internes. Seule exception : le premier module à parler