vault backup: 2026-04-22 20:01:03
This commit is contained in:
parent
047d22f16e
commit
0f238959d8
@ -241,3 +241,17 @@ Catégories possibles :
|
|||||||
- Si mes tests passent mais Jerem dit que ça ne marche pas → **mon test est faux, pas son observation**. Changer d'angle immédiatement.
|
- Si mes tests passent mais Jerem dit que ça ne marche pas → **mon test est faux, pas son observation**. Changer d'angle immédiatement.
|
||||||
- Jamais dire "c'est fixé" sans avoir validé sur le vrai parcours user. Préférer "teste et dis-moi" à "c'est fixé".
|
- Jamais dire "c'est fixé" sans avoir validé sur le vrai parcours user. Préférer "teste et dis-moi" à "c'est fixé".
|
||||||
**Source** : conversation 2026-04-20 → 2026-04-21 (projet Diet Engine)
|
**Source** : conversation 2026-04-20 → 2026-04-21 (projet Diet Engine)
|
||||||
|
|
||||||
|
### 2026-04-22 — #pattern — Ne JAMAIS certifier "zero regression" sans tests end-to-end réels
|
||||||
|
**Contexte** : batch d'audit Diet Engine, 9 commits, +1100 lignes. J'ai certifié noir sur blanc à Jerem "aucune régression, tout transparent sauf L". Il a trouvé 2 régressions en 2 minutes (cycles impossibles à créer à cause d'`express.json limit 100kb` + propriétés Notion Type/Sport manquantes). Jerem a explicitement râlé : "tu m'avais certifié qu'il n'y aurais pas de regression, qu'est ce qu'il s'est passé ?"
|
||||||
|
**Apprentissage** :
|
||||||
|
1. **Analyse théorique ≠ test.** Lire le diff, vérifier syntax avec `node --check`, grep des usages — ça me dit que le code compile. Ça ne dit PAS que le comportement reste identique. Le syntax check est un filet passoire-fin.
|
||||||
|
2. **Ne jamais mettre "zero regression" dans un engagement écrit** sans avoir **lancé le serveur** et **testé chaque endpoint critique** avec curl/scénarios user réels. Si je n'ai pas le temps/budget de tester, dire "à vérifier par ton test" plutôt que "certifié zero-impact".
|
||||||
|
3. Le cas concret qui m'a piégé : j'ai **changé le body limit de 10mb à 100kb** (measure DoS P1). Théoriquement : tous les PATCH/POST font < 100kb. En réalité : PATCH cycle avec aliments_recommandes pré-remplis + phases peut faire 300kb, et l'upload-image (5mb base64) était complètement cassé car le middleware local 6mb n'est jamais atteint — le global 100kb rejette 413 avant.
|
||||||
|
4. J'ai aussi raté 3 routes Notion (`runNotionExport` mode guide_macro + `createDietPage`) qui auraient dû avoir les mêmes propriétés Type/Sport que `decoupe.js`. Ce n'était pas une régression de mes modifs stricto sensu, mais **je l'aurais vu en exportant une diète réelle en test**.
|
||||||
|
**Implication DAEMON** :
|
||||||
|
- **Avant** tout commit "chore/fix/security" non-trivial, **lancer le serveur local** (`node src/index.js` avec les vraies data) et tester **au minimum** : les routes mutantes modifiées + les gros payloads (upload, diètes complètes) + les flows qui matchent les modifs.
|
||||||
|
- Pour un audit avec >50 items traités, **ne pas push avant un smoke test complet scripté** (bash + curl testant les principaux endpoints en une seule passe). Budget : 30-45 min sur un gros batch. C'est cheap vs le coût de perdre la confiance de Jerem.
|
||||||
|
- Formule à bannir : "aucune régression, tout transparent". Formule acceptable : "j'ai testé A/B/C en local, ils passent ; D/E/F théoriquement OK mais à vérifier de ton côté".
|
||||||
|
- Si Jerem dit "tu es sûr ?", TOUJOURS répondre en listant **ce que j'ai testé concrètement**. S'il n'y a rien, dire "non, je ne suis pas sûr — voici ce qu'il faudrait tester".
|
||||||
|
**Source** : conversation 2026-04-22 (batch audit Diet Engine, régressions cycles + propriétés Notion)
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user