docs(memory): log the release-flow lesson

MEMORY/LESSON.md

@@ -17,3 +17,4 @@
 - [2026-09-01 22:35] Premier run du CI rouge sur UN test (`zsh loader`, absent d'`ubuntu-latest`). Le vrai défaut était ailleurs : le cas `fish` du même fichier portait déjà `test.skipIf(!Bun.which("fish"))` et se **skippait silencieusement** en CI depuis toujours — un CI vert me l'aurait caché indéfiniment. → Une garde `skipIf(outil absent)` protège la machine du contributeur mais **supprime la couverture là où elle compte le plus**. Sur le runner, installer l'outil (`sudo apt-get install -y zsh fish` ; ni l'un ni l'autre n'est préinstallé sur Ubuntu 24.04) ET faire échouer le job sur tout `skip` — sinon la garde transforme un test mort en test vert. Corollaire d'API : `bun:test` n'a pas de skip par ligne dans `test.each` (oven-sh/bun#4469 ouverte) — passer par une boucle `for`, et vérifier la garde par contrôle négatif (PATH privé du binaire → `1 skip / 0 fail`, contre `1 fail` avant).
 - [2026-09-01 22:35] J'ai annoncé au proprio « `runSetup` n'écrit que sous `~/.cursor` » pour justifier un correctif — le challenger a mesuré des `append` dans `~/.zshrc` / `~/.bashrc` et un `conf.d/*.fish` (`shell-installers.ts:25,60,68-74`). Le correctif restait bon, mon argument était faux, et il minimisait ce qu'il évitait. → Un périmètre d'écriture s'énonce après un `grep` des primitives d'écriture du module (`writeFileSync`, `appendFileSync`, `spawn`), jamais d'après le nom des chemins qu'on a en tête. Se tromper « en faveur » de sa propre conclusion reste une erreur — et ici la vérité renforçait le correctif.
 - [2026-09-01 22:02] `tests/marketplace-sparse-install.test.sh` compare le worktree à `git archive HEAD` : un `git rm` non commité le fait échouer en ENOENT sur un fichier que HEAD contient encore — échec purement mécanique, sans rapport avec le défaut testé. → Face à une suite qui se réfère à HEAD, tout changement d'INDEX non commité est un faux échec : trancher dans un `git clone . /tmp/x` où l'on peut commiter localement, jamais en commitant sur la branche pour « voir si ça passe ».
+- [2026-09-04 07:55] Cycle de release mené moitié-moitié : le bump `1.2.40 → 1.2.41` est bien passé par la PR #4 (CI verte, merge `--merge`), puis j'ai poussé `chore(release): 0.1.2` — CHANGELOG + tag — **directement sur `main`**. Le skill `fuse-commit-pro:git-flow` l'interdit noir sur blanc (« `main` → never commit directly », « ❌ Commits on main "to save time" — bypasses review, breaks CI gates »). Le workflow écoutant aussi `push: [main]`, la CI est passée au vert APRÈS coup et le défaut de processus est resté invisible : `v0.1.2` tague un commit que personne n'a revu. → Le CHANGELOG et le bump appartiennent à la **branche de feature, avant le merge** — c'est précisément la raison d'être du `--merge` (jamais `--squash`) : le tag doit pointer sur le commit de bump qui a transité par la PR. Corollaire de méthode, plus coûteux que l'erreur elle-même : j'ai demandé au propriétaire « veux-tu que les releases passent par une PR ? » alors que la réponse était écrite dans un skill du dépôt. Avant toute question de convention (git, commit, release, versionnage), **grep les skills d'abord** — `fuse-commit-pro:git-flow`, `commit-detection`, `post-commit` ; demander ce qui est déjà écrit fait perdre un tour et signale qu'on n'a pas lu.