Portes de qualité

Configurez des seuils qui avertissent ou interdisent les dépendances si mainteneurs, activité, sécurité ou licences échouent.

À quoi servent les portes de qualité

Les portes de qualité sont des politiques d'organisation composées de règles. Une règle se déclenche quand une dépendance échoue un ou plusieurs seuils. Elle émet alors un avertissement ou interdit le package. Il n'y a pas d'action Autoriser : un package qui respecte tous les seuils renseignés passe simplement.

Les portes de qualité sont distinctes de la gouvernance par catégories et des politiques de licence.

Ce ne sont pas non plus les seuils de sévérité PR / API (prCheckSeverityThreshold, apiGateSeverityThreshold). Ces champs pilotent les contrôles PR GitHub / External Status Checks MR GitLab (vulns / secrets / SAST) et l’attente API publique / CLI --wait / MCP, et ne sont pas liés aux règles Quality Gates. Voir Contrôles PR et API scans.

Configuration dans les paramètres

Ouvrez Paramètres → Portes de qualité. Créez une politique, puis des règles.

Chaque règle a :

Action — Avertissement (signal / score) ou Interdire (non conforme ; peut faire échouer les contrôles PR).
Périmètre — Écosystèmes (aucun coché = tous : npm, PyPI, RubyGems, Maven, Cargo, Composer, Go/gomod) et catégories de dépendances optionnelles.
Mode — Seuils (formulaire) ou Expressions (faits package + opérateurs allowlistés). Un seul mode par règle.

Seuils opérationnels

Seuil	Comportement	Limites
Mainteneurs minimum	Échoue si le nombre de mainteneurs est inférieur	Couverture plus faible sur Maven
Jours max depuis la dernière release	Échoue si une date de release connue dépasse N jours	—
Respecter les politiques de licence org	Échoue si la licence ne satisfait pas les politiques actives	Correspondance SPDX / alias exacte (même moteur que la politique de licences) ; `MIT-0` ≠ `MIT`
Licences autorisées / interdites	Liste blanche / noire sur la chaîne de licence	—
Doit être marqué maintenu	Échoue seulement si explicitement non maintenu	Données manquantes ≠ échec
Doit être marqué populaire	Échoue seulement si explicitement non populaire	Données manquantes ≠ échec
Stars, forks, issues, commits GitHub	Comparés aux facts GitHub synchronisés	Repo GitHub lié requis
Téléchargements min (30 jours)	Comparés aux facts de téléchargement	Plus fiable pour npm ; ailleurs souvent 0
Téléchargements totaux minimum	Comparés au total lifetime	npm : somme en fenêtres ≤18 mois depuis la création du package
Vulnérabilités connues maximum	Échoue si le compte d’advisories OSV dépasse le seuil	Rempli à la sync des facts (niveau package ; latest si connu)
Fréquence minimale de releases	Échoue si les releases/an estimées sont sous le seuil	Heuristique d’historique registry
Taille max du package (octets)	Échoue si la taille syncée dépasse le seuil	Taille registry quand disponible
Dépendances directes maximum	Échoue si le nombre de dépendances directes dépasse le seuil	—

Expressions (policy 1.1.0)

Le mode expressions construit des règles en lignes { fact, operator, value } avec correspondance all ou any. Opérateurs allowlistés (eq, neq, gt, gte, lt, lte, in, not_in, is_true, is_null) — pas de scripts libres. Les facts sont ceux de la sync package (ex. vulnerabilityCount, maintainersCount, daysSinceLastRelease). Les facts manquants suivent toujours factsSync.onMissingFact. Listes de licences et « respecter les politiques de licence » restent en mode Seuils uniquement.

Facts manquants

Le comportement est défini dans Paramètres → Dependency Advisor (factsSync.onMissingFact), pas par règle :

Réglage	Effet sur les règles qui ont besoin du fact manquant
Autoriser (défaut)	Ignore ce seuil — les facts manquants ne font pas échouer la règle
Avertissement	La règle est considérée comme matchée (warning / impact score)
Interdire	La règle est considérée comme matchée (non conforme)

Une valeur synchronisée à 0 (par ex. zéro mainteneur après sync réussie) est une donnée réelle et reste évaluée. Les stats packages se remplissent progressivement sur la semaine ; les premiers scans ont souvent des facts en attente. Le compteur de vulnérabilités est omis tant que la sync OSV n’a pas réussi (null en cas d’échec), donc les réglages de facts manquants s’appliquent.

Gérer via MCP / LLM

Avec un service token package-finder:read et policy:read (policy:write pour importer), vous pouvez demander à un client MCP :

« Évalue lodash sur npm contre nos politiques. » → evaluate_package
« Exporte nos portes de qualité en policy bundle. » → export_policy_bundle avec kind=quality
« Valide ce bundle quality, puis dry-run import. » → validate_policy_bundle / import_policy_bundle avec dryRun=true
« Ajoute une règle qui interdit les packages avec plus de 0 vulnérabilités connues. » → exporter le bundle quality, éditer conditions.maxVulns: 0 (ou une expression sur vulnerabilityCount), valider, puis importer. Les bundles utilisent apiVersion: codecleared.io/policy/1.1.0.