feat: le seuil de puce devient un réglage, et les libellés suivent la configuration

[lostmind84]

Deux choses, à ne pas confondre : un correctif que la seconde a mis au jour, et un réglage.

Le correctif

Les libellés des rayons de la grille venaient du snapshot — donc de la table SQLite categories, que seul un import met à jour — au lieu de la configuration. Renommer un rayon dans config.json n'atteignait l'écran qu'au prochain catalogue publié par un producteur : un rayon renommé le lundi gardait son ancien nom jusqu'à l'export du vendredi, sans rien à l'écran pour le dire.

§10.2 bis dit pourtant que la configuration porte le libellé, le rang, la couleur et « montrer cette catégorie sur ce poste », et §11.4 que ces quatre-là rechargent à chaud. Le commentaire du cache, dix lignes plus haut, l'écrivait déjà : « les catégories, les tarifs et les trois réglages d'écran viennent de la CONFIGURATION ». C'est la clé du cache qui avait raison, pas la boucle.

Ce que ce correctif ne fait pas, et c'est écrit dans le code. Une grille déjà chargée dans un navigateur ne va pas rechercher le nouveau libellé d'elle-même : le front ne redemande le catalogue que si catalog_count ou presentation_digest bouge, et un renommage ne bouge ni l'un ni l'autre. Le serveur sert le bon libellé au prochain GET ; il faut donc un rechargement de page. Élargir l'empreinte aux catégories fermerait ce dernier cran — c'est une décision d'architecture, laissée ouverte et nommée dans les commentaires plutôt que tranchée ici.

Le réglage — ui.min_products_for_chip (ADR-059)

Entier, défaut 5, plancher 1, pas de plafond. Appliqué à chaque catégorie séparément, sur son propre effectif de tuiles servies.

Sous le seuil, une catégorie perd sa puce de filtre, jamais ses tuiles : ses produits restent dans « Tout » et à la recherche. Retirer vraiment une catégorie de l'écran reste categories[].visible, et les deux ne se confondent pas.

MIN_PRODUCTS_FOR_CHIP était une constante du front dont le commentaire disait « pas un réglage (ADR-025) ». Ce qu'ADR-024 a mesuré est qu'un seuil doit exister — en 2022, « Autres » menait à un seul produit, soit un quart de barre de navigation pour une tuile. Ce qu'aucune mesure ne dit, c'est pourquoi cinq plutôt que trois ou huit : la forme d'un catalogue s'inverse d'un export à l'autre (flv.csv donne A = 140, V = 118, L = 68, F = 29 ; flv_1.csv donnait L = 84, V = 58, F = 10, A = 1). ADR-059 amende ADR-024 sans le renverser, sur le précédent exact d'ADR-057 pour ui.grid_columns.

Conséquence assumée : sans plafond, un seuil supérieur au plus gros rayon laisse la barre avec « Tout » seul, et rien ne l'annonce avant l'enregistrement. C'est le prix de « un seul paramètre », réversible en revenant sur le champ, et c'est écrit dans ADR-059.

Le comportement livré ne bouge pas

Un fichier qui ne porte pas la clé — et le fichier livré ne la porte pas, délibérément — se relit au défaut : Config.UnmarshalJSON corrige le zéro, comme il le fait déjà pour update.repository.

Sans cette précaution, le contrôle 50 aurait refusé la configuration livrée, et les bancs auraient servi un seuil de 0 — une puce à toute catégorie, y compris vide. C'est le défaut du 28/07/2026 que config_test.go nomme déjà. ui.grid_columns y échappe parce que son défaut sûr est le zéro ; le seuil de puce n'a pas cette chance.

Ce que la relecture a trouvé, au-delà du périmètre

• Quatre commentaires Go annonçaient « the 48 controls » alors qu'il y en avait 49 puis 50 ; §11.3 affichait « 49 numéros, 47 contrôles ». Ces totaux cèdent la place au critère que la liste énumérée fait vivre — un numéro retiré n'est jamais repris. Le passage portait déjà une note disant qu'il s'était trompé une fois ; la leçon est conservée, la date généralisée.
• Un commentaire comparait 355 lignes reçues à 107 tuiles pesables. La paire cohérente est 331 / 107.
• Le libellé d'administration disait « Produits minimum pour afficher une catégorie » — le contresens exact, servi sans note dans la barre de refus et le tableau de différences. Devenu « Tuiles minimum pour donner sa puce à une catégorie ».

Ce qui reste ouvert, volontairement

web/src/App.svelte — activeCategory n'est pas réinitialisé quand un seuil relevé retire la puce active : la grille reste filtrée, aucune puce n'est allumée, et rien ne l'explique. Récupérable en touchant « Tout ». Le défaut préexiste pour categories[].visible ; cette branche est ce qui rend le seuil modifiable en cours de service. C'est un changement de comportement de l'écran client, pas une correction — il mérite sa propre décision.

Hors branche : le décompte des contrôles est encore faux dans une quinzaine d'endroits, à trois valeurs différentes. Chantier à part.

Vérification

make.ps1 test        exit 0   passe -race puis passe CGO_ENABLED=0, boundary, deps
make.ps1 vet         exit 0
make.ps1 front-check exit 0   svelte-check 373 fichiers / 0 erreur
                              vitest 38 fichiers / 1008 tests
                              80 586 o gzip pour un budget de 112 640 — 71,5 % de marge

internal/web/dist/ est régénéré et committé : le dépôt a déjà livré « l'écran d'avant » pour l'avoir oublié.

Deux garanties vérifiées en les cassant. Figer chips() sur la constante rend rouge le cas à seuil 70. Relâcher le contrôle 50 de < 1 à < 0 ne cassait rien — le plancher n'était pinné par aucun test ; comblé, et la mutation refaite échoue désormais exactement sur le sous-cas 0.