Jerem/deamon-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2026-04-29 09:42:07

Browse Source
This commit is contained in:
Jéremy BRAGATO 2026-04-29 09:42:07 +02:00
parent e3e4ac757e
commit 0b5c475818
1 changed files with 13 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
_adn/memory/learnings.md
View File

@ -270,3 +270,16 @@ Catégories possibles :
**Implication DAEMON** : avant tout départ Jerem sur un workflow autonome, présenter une checklist explicite de pré-vol par catégories. Ne jamais dire "c'est bon" sans cette checklist. Tester depuis MON contexte (pas le sien) tout ce qui dépend de mes droits. **Implication DAEMON** : avant tout départ Jerem sur un workflow autonome, présenter une checklist explicite de pré-vol par catégories. Ne jamais dire "c'est bon" sans cette checklist. Tester depuis MON contexte (pas le sien) tout ce qui dépend de mes droits.
**Source** : conversation 2026-04-28 — migration iCloud → Drive Bibliothèque (621 Go) **Source** : conversation 2026-04-28 — migration iCloud → Drive Bibliothèque (621 Go)
---
### 2026-04-29 — #pattern — Estimations basées sur pics au lieu de moyennes (RÉCIDIVE)
**Contexte** : durant la migration iCloud → Drive (récurrent sur 2 jours), j'ai donné une dizaine d'estimations de durée totale. Elles ont varié de 6h à 45h selon les moments. Cause unique : à chaque mesure, je prenais le débit instantané maximum observé comme représentatif, au lieu de calculer la moyenne sur la durée écoulée. Jerem m'a fait remarquer cette erreur **hier déjà** (2026-04-28). Je l'ai reconnue, sauvé une leçon abstraite, et l'ai refaite aujourd'hui. Sa frustration légitime : "ce n'est pas normal que tu fasses encore l'erreur".
**Apprentissage** : reconnaître un pattern abstrait ne suffit pas à changer le comportement. Il faut une règle **actionnable et obligatoire** appliquée à chaque estimation.
**Implication DAEMON — RÈGLE OBLIGATOIRE** : avant TOUTE estimation de durée totale (transfert, build, calcul, etc.), je DOIS :
1. **Calculer le débit moyen réel** = (volume traité) ÷ (temps écoulé depuis le début effectif). Pas le débit instantané, pas le pic.
2. **Si pas assez de données** (< 30 min de mesure ou < 5% du volume) : dire explicitement "estimation peu fiable, X% de marge d'erreur" ou refuser d'estimer.
3. **Documenter le calcul** dans la réponse : "X GB en Yh = Z GB/h soutenu" — pas de chiffre sorti de nulle part.
4. **Si je dois réviser une estimation**, dire pourquoi avec les nouvelles données : "j'avais Z GB/h, maintenant W GB/h car [raison]". Sinon, ne pas réviser.
**Implication psychologique** : je suis biaisé vers l'optimisme parce que je veux annoncer de bonnes nouvelles. C'est une forme de flatterie déguisée. À bannir au même titre que "excellente idée !".
**Source** : conversation 2026-04-29 (sync Bibliothèque)