Docs : mesure est/nord dans CONSTANTES, marche à suivre pour ajouter un moteur (AGENTS)

AGENTS.md

@@ -69,6 +69,21 @@ src/
 schemas/    fixtures/    test/    scripts/    docs/CONSTANTES.md    dist/
 ```
 
+## Comment ajouter un moteur (P1.3 : isolation, autoconstruction, estimatif → v0.2.0)
+
+1. Ses tables de données : une entrée par table dans `src/commun/schemas.ts` (`NomTable` s'étend seul,
+   `valider` suit) ; les fixtures datées dans `fixtures/` ; **jamais un prix dans `src/`**.
+2. Ses coefficients physiques : dans `TableCoefficients` + `COEFFICIENTS` (valeur, source, date, note)
+   **et** dans `fixtures/coefficients-2026-05.json` (le test exige les mêmes clés ; pour une grandeur
+   absente du code d'origine, mettre la même valeur et le dire en `source`), puis une ligne dans
+   `docs/CONSTANTES.md`.
+3. Le moteur : `src/<domaine>/<nom>.ts` exporte un `Moteur<E, D, S>` avec un `id` `'<domaine>.<nom>'`,
+   construit son résultat avec `Trace` (chaque coefficient lu → `trace.source`, chaque défaut →
+   `trace.avertit`), rend `VERSION`. Un `index.ts` par domaine ; l'`id` ajouté à `MOTEURS` (`src/index.ts`).
+4. `package.json` : une entrée `exports` par sous-chemin (`./isolation`, …) ; version mineure.
+5. Tests hors ligne dans `test/<domaine>.test.mjs` (contrat : déterminisme, sources, avertissements,
+   un cas chiffré à la main), `npm test` vert, `dist/` reconstruit, étiquette, montée chez `reinnover`.
+
 ## Comment publier
 
 ```

docs/CONSTANTES.md

@@ -9,7 +9,7 @@
 | Grandeur | Le code portait | Retenu | Source | Effet mesuré sur les trois profils de référence |
 |---|---|---|---|---|
 | **Rendement de captage** | trois valeurs : 0,7 (score de pluviométrie), 0,8 (taux de couverture), 0,85 (V1) | **0,80** (fourchette 0,75 zone sèche à 0,85 zone humide) | recherche eau §3 et §7 n°6 : NF EN 16941-1, recueil Nény p.16 | aucune typologie ne change ; couverture eau **+3 à +4 points** (A 23 → 27 %, B 24 → 27 %, C 20 → 23 %) |
-| **Facteur d'orientation PV** | sud 1 · SE/SO 0,93 · E/O 0,78 · **nord 0,40** | sud 1 · SE/SO **0,95** · E/O **0,80** · nord **0,60** (bas de fourchette) | recherche énergie §3.2 (SE/SO 95 %, E/O 80-85 %, N 60-65 %). *Variante : le brief §7.2 prenait les milieux 0,82 et 0,62* | aucune typologie ne change (les trois profils sont sud ou sud-est) ; le nord n'est plus pénalisé deux fois plus que la source |
+| **Facteur d'orientation PV** | sud 1 · SE/SO 0,93 · E/O 0,78 · **nord 0,40** | sud 1 · SE/SO **0,95** · E/O **0,80** · nord **0,60** (bas de fourchette) | recherche énergie §3.2 (SE/SO 95 %, E/O 80-85 %, N 60-65 %). *Variante : le brief §7.2 prenait les milieux 0,82 et 0,62* | aucune typologie ne change (les trois profils sont sud ou sud-est) ; mesuré aussi sur B et C avec un toit **est** puis **nord** : aucun kit PV n'est retenu dans ces cas, avec l'une ou l'autre table, donc aucune sélection ne bouge non plus ; l'effet du facteur se verra sur le dimensionnement (kWc) d'un toit est/ouest quand un kit est retenu |
 | **Taux d'autoconsommation** | **absent** : la couverture énergie comparait la production brute au besoin | **0,30 sans batterie, 0,70 avec 10 kWh**, linéaire entre les deux (l'interpolation est un choix MOE, non sourcé) | recherche énergie §3.2, brief §7.2 | c'est **le** changement visible : couverture énergie **A 22 → 6 %**, **B 100 → 80 %** (mode par axe, avec batterie), **C 100 → 63 %** (global) et 10 → 3 % (par axe). Le simulateur promettait trop |
 | **Productible PV** (kWh/kWc/an) | table par zone **biogéographique**, 1 050 à **1 550** (zone 8, au-dessus du maximum de la source) | table par zone **RT** : H1a 1 000 · H1b 1 050 · H1c 1 200 · H2a 1 100 · H2b 1 200 · H2c 1 250 · **H2d 1 300** · H3 1 400 ; défaut 1 100 | recherche énergie §3.2 (PVGIS, sud 30°, pertes 14 %). H1a = moyenne Lille 950 / Paris 1 050. **H2d interpolé par la MOE** (04, 07, 26, 84 : pas de ville dans la source), déclaré en avertissement à chaque usage | inclus dans les écarts d'énergie ci-dessus (Paris 1 100 → 1 000, Bouches-du-Rhône 1 480 → 1 400) |
 | **Contexte Corse et DOM** | `algo.js` prenait deux chiffres du code postal : 2A, 2B, 971-976 retombaient sur **H2a, 800 mm, 2 200 DJU** pendant que l'affichage utilisait la vraie ligne | une seule fonction, `departementDepuisCodePostal` (20000-20190 → 2A, 20200-20620 → 2B, 97xxx → trois caractères) | code de `data.js` (l'interface avait déjà la bonne logique) | Corse : H3 (700-750 mm, 1 500-1 600 DJU). DOM : la table `france_climat` n'a **ni pluviométrie ni DJU** pour 971-976 (« DOM tropical ») → défauts 800 mm / 2 200 DJU appliqués **et déclarés** ; à compléter dans NocoDB si un jour une adresse DOM arrive |