Consigner les arbitrages sur les tags et le filtre

Section 16 de decisions.md : pourquoi des étiquettes libres plutôt qu'un
référentiel, pourquoi un filtre conjonctif plutôt que disjonctif, pourquoi il
n'est pas enregistré alors que le masquage par l'œil l'est — avec un tableau qui
oppose les deux —, pourquoi la couleur d'un tag est calculée et non choisie, et
pourquoi un tag trop long est tronqué là où une date invalide bloque tout.

Le README décrit l'usage : saisie des tags, filtre cumulatif, portée limitée à la
session.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/decisions.md

@@ -218,3 +218,46 @@ Attention en modifiant `centrerSur` : `scrollLeft` porte sur la grille entière,
 première colonne est celle des libellés. Comme elle est `sticky`, elle masque en
 permanence les premiers pixels de la vue, et le centre utile des couloirs est décalé
 d'une demi-largeur de colonne par rapport au centre de la frise.
+
+## 16. Tags libres et filtre conjonctif
+
+Passé une dizaine de projets, la frise devient un mur : on veut n'y voir que les projets
+clients, ou que ceux d'un pôle. D'où des **tags** sur le projet, et un filtre.
+
+**Étiquettes libres, pas de référentiel.** Aucune liste de tags autorisés n'est tenue
+quelque part : les tags disponibles sont ceux que portent les projets, et un tag disparaît
+de la barre de filtres dès qu'il n'orne plus rien. Un référentiel séparé aurait exigé une
+interface pour le gérer, et se serait désynchronisé. La contrepartie — la dérive
+orthographique, « client », « Clients », « client final » — est traitée par deux gardes :
+la comparaison ignore la casse, et le dialogue d'un projet propose en un clic les tags déjà
+employés ailleurs.
+
+**Le filtre exige *tous* les tags cochés**, pas au moins un. Cocher un tag de plus resserre
+donc toujours la sélection : on part du tout et on élague, sans jamais voir la frise se
+repeupler en cochant. La disjonction se comporte à l'inverse, et il faut alors relire la
+liste des tags actifs pour savoir dans quel sens la prochaine case va jouer.
+
+**Le filtre n'est pas enregistré.** C'est un état de vue, comme la fenêtre temporelle
+(décision 15) : un filtre qui survivrait au rechargement rouvrirait le planning amputé sans
+qu'on se souvienne pourquoi. Le masquage par l'œil (`hidden`), lui, est bien enregistré —
+et les deux ne font pas la même chose :
+
+| | Filtre par tags | Œil (`hidden`) |
+|---|---|---|
+| Portée | La vue entière, libellé compris | Les barres seules, le libellé reste grisé |
+| Durée de vie | La session | Enregistré dans le fichier |
+| Question posée | « Je ne regarde que les projets clients » | « Ce projet existe, mais il encombre ma frise » |
+
+**La couleur d'un tag est calculée, pas choisie** : une teinte HSL dérivée du nom par
+hachage. Rien à stocker, rien à saisir, et le même tag garde sa couleur partout. Des
+collisions de teinte sont possibles et sans gravité — le nom est toujours écrit à côté.
+
+**Un tag trop long est tronqué, pas refusé.** Contrairement à une date invalide, qui bloque
+le chargement en nommant le fautif, la longueur d'un tag est cosmétique : refuser d'ouvrir
+un planning entier pour un libellé bavard serait disproportionné. La limite est donc
+appliquée en normalisant, ce qui la rend vraie par construction — aussi bien pour un fichier
+édité à la main que pour une saisie dans le dialogue.
+
+Créer un projet alors qu'un filtre est actif **préremplit ses tags** avec ceux du filtre :
+sans cela, le nouveau venu naîtrait invisible, hors de la vue depuis laquelle on vient de le
+demander.