diff --git a/common/veille-macbook-brain-watch-filtre-prerelease.md b/common/veille-macbook-brain-watch-filtre-prerelease.md
new file mode 100644
index 0000000..010f600
--- /dev/null
+++ b/common/veille-macbook-brain-watch-filtre-prerelease.md
@@ -0,0 +1,23 @@
+# MacBook Brain Watch — filtrage prerelease + consolidation (29/07/2026)
+
+## Contexte
+Workflow n8n `9MkE8Fx3ZlY485Y5` ("INFRA | OpenHuman Watch", cron 4h) surveille les releases GitHub de deux projets candidats pour le futur stack local du MacBook (OpenHuman `tinyhumansai/openhuman`, Vellum `vellum-ai/vellum-assistant`). Un premier fix (25-27/07) avait remplacé la dédup `lastSeenId` unique par un historique d'IDs vus (array cappé à 30), pour stopper le renvoi en boucle causé par l'alternance stable/prerelease en tête du flux Atom Vellum.
+
+## Symptôme persistant après le premier fix
+18 notifications Telegram+Email reçues en ~24h (29/07), toutes issues d'OpenHuman/Vellum. Le premier fix corrigeait bien la boucle de re-notification, mais pas la cause de fond : `vellum-ai/vellum-assistant` publie un tag `-staging.N` "cherry-pick" à chaque build interne avant la release finale (ex. `v0.11.0-staging.1`, `.2`, `.3` puis `v0.11.0`), et chaque tag a un ID Atom unique → chacun est légitimement "nouveau" pour la dédup et génère sa propre notif Telegram + email.
+
+## Cause racine
+Confusion entre deux problèmes distincts : "ne pas re-notifier un ID déjà vu" (résolu le 25-27/07) vs "ne pas notifier chaque changement de nom de build/tag interne" (jamais traité). Vérifié en direct sur les flux Atom réels : sur les 10 dernières entrées Vellum, 7 sont des `-staging.N`, seules 3 sont des releases stables.
+
+## Fix appliqué
+Node "🔍 Fetch Releases GitHub & Vellum" modifié :
+- Ajout d'un filtre regex `/-(staging|rc|beta|alpha|dev|nightly|pre|preview|cherry)/i` sur `id`/`title` : les tags de build interne sont marqués vus (pour ne jamais les retraiter) mais exclus de la notification.
+- Consolidation : au lieu d'un Telegram + un email par entrée détectée, une seule notification Telegram et un seul email par exécution, regroupant toutes les releases stables trouvées (toutes projets confondus).
+- Validation faite en conditions réelles : code testé dans le container n8n avec les vrais flux Atom (via `node -` + fichiers copiés par `docker cp`), confirmant que le filtre élimine bien 7/10 entrées Vellum bruit et conserve les vraies releases (OpenHuman conserve son rythme de sorties stables, qui reste un signal légitime de maturité du projet).
+- Déploiement : UPDATE `workflow_entity.nodes` via psql (payload passé en stdin, jamais en argument de ligne de commande, pour éviter les limites de taille/quoting) puis `docker restart n8n` (obligatoire : n8n ne recharge pas les nodes actifs à chaud). Vérifié post-restart : n8n healthy, workflow toujours actif.
+
+## Non traité (dette déjà connue, inchangée)
+Token Telegram en clair dans le node Code — nécessite un rebranchement sur credential `ND_Telegram`, changement plus large à faire séparément avec validation UI.
+
+## Piège à retenir
+Sur un flux Atom GitHub de projet à cadence CI élevée, la dédup par ID seule ne suffit jamais à filtrer le bruit : elle empêche la répétition mais pas le volume. Il faut un filtre de contenu (naming convention prerelease/staging/rc) en plus de la dédup, et idéalement consolider en un seul message par cycle plutôt qu'un message par item.