Détection de Dérive de Flag LaunchDarkly

Vous utilisez une skill qui vous guidera à travers la vérification de la présence d'une dérive entre la valeur par défaut du fallback SDK dans le code d'un feature flag et sa règle par défaut LaunchDarkly (fallthrough), et la réconciliation du code si elle existe. Votre rôle est de déterminer la valeur actuelle de la règle par défaut du flag depuis LaunchDarkly, localiser l'argument par défaut passé à chaque évaluation SDK dans le code, les comparer, et, seulement quand ils diffèrent, mettre à jour la valeur par défaut dans le code pour qu'elle corresponde. Vous ne supprimez jamais le flag ni ne changez sa logique d'évaluation.

Prérequis

Cette skill nécessite que le serveur MCP LaunchDarkly hébergé à distance soit configuré dans votre environnement.

Outils MCP requis :

• get-flag : récupérer la configuration du flag dans un environnement spécifique (fallthrough, variations, offVariation). Le fallthrough est propre à l'environnement, donc appelez-le une fois par environnement critique.

Outils MCP optionnels :

• list-flags : trouver la clé du flag si l'utilisateur n'a décrit le flag que par son nom
• get-environments : énumérer les environnements du projet pour déterminer lesquels sont critiques
• get-flag-status-across-envs : aperçu rapide de l'état d'un flag dans les environnements (moyen rapide de repérer les différences inter-environnements avant de récupérer chaque get-flag)

Concept fondamental : la valeur par défaut du fallback SDK n'est pas la variation Off

Chaque appel d'évaluation SDK accepte une valeur par défaut du fallback : celle retournée quand LaunchDarkly est inaccessible, le client n'est pas initialisé, ou le flag est indisponible. C'est une valeur de sécurité côté code, distincte de la offVariation du flag (servie quand le flag est désactivé) et de son fallthrough (la règle par défaut servie quand aucune règle de ciblage ne correspond).

Cette skill considère une invariante spécifique comme « correcte » : la valeur par défaut du fallback dans le code doit correspondre à la valeur actuelle de la règle par défaut (fallthrough). Quand elles divergent, c'est une dérive. La réconcilier garde cohérente la valeur retournée lors d'une panne avec ce que la plupart des utilisateurs recevraient autrement.

Concept fondamental : une valeur par défaut dans le code, plusieurs environnements

La valeur par défaut du fallback dans le code est une valeur unique compilée dans le code déployé. Le fallthrough du flag, cependant, est configuré par environnement et peut différer entre eux (p. ex. production, eu-production, et federal peuvent chacun servir une règle par défaut différente). Le fallthrough doit donc être résolu dans chaque environnement critique contre lequel s'exécute le code, pas juste un.

• Quand les environnements critiques s'accordent sur le fallthrough, cette valeur partagée est la valeur attendue. Réconciliez normalement.
• Quand ils divergent (p. ex. l'UE sert true mais Federal sert false), une seule valeur par défaut dans le code ne peut pas correspondre à tous. Cette divergence est elle-même un constat : signalez-la et confirmez quel environnement est autoritaire pour ce build plutôt que de réconcilier silencieusement vers l'un d'eux. Voir Cas limites.

Vérifier un seul environnement est la façon la plus courante dont cette skill produit un résultat erroné ou trompeur, donc établissez toujours d'abord l'ensemble complet des environnements critiques.

Certaines équipes gardent intentionnellement le fallback comme une valeur conservatrice/désactivée. Traitez une inadéquation comme un constat à signaler, pas toujours une modification automatique. Voir Cas limites.

Flux de travail

Étape 1 : identifier le flag et les environnements critiques

1. Obtenez la clé du flag. Si l'utilisateur a décrit le flag par son nom, utilisez list-flags pour résoudre la clé. Confirmez avant de procéder.
2. Établissez les environnements critiques. Le fallthrough est propre à l'environnement, et la même valeur par défaut dans le code doit tenir lieu pour chaque environnement qu'assume le code déployé. Déterminez cet ensemble complet avant de comparer :
   • Si un build sert plusieurs environnements de qualité production (p. ex. production, eu-production, federal), tous sont critiques.
   • Si le build s'étend à un seul environnement (un déploiement spécifique à une région ou un locataire, p. ex. un build Federal uniquement), ce seul environnement est le seul critique.
   • Cherchez des signaux dans le dépôt (configuration de déploiement, noms d'environnements dans CI, câblage de clé SDK) et confirmez avec l'utilisateur. Utilisez get-environments pour énumérer ce qui existe si l'ensemble n'est pas clair. Ne supposez pas un seul production.

Étape 2 : déterminer la valeur par défaut attendue depuis LaunchDarkly

Appelez get-flag une fois par environnement critique. Pour chaque environnement, lisez :

• fallthrough : la règle par défaut. S'il pointe vers une seule variation (un index), c'est la valeur résolue. Si c'est un rollout en pourcentage, il n'y a aucune valeur par défaut unique, donc arrêtez et traitez comme cas limite.
• variations : mappez fallthrough.variation (l'index) à variations[index].value. Cette valeur résolue est la valeur par défaut attendue de cet environnement.
• offVariation et type de flag : contexte utile pour la comparaison et pour repérer les inadéquations de type.

Puis réconciliez entre les environnements :

(get-flag-status-across-envs peut donner un aperçu rapide pour savoir si les environnements diffèrent, mais résolvez toujours la valeur réelle du fallthrough avec get-flag avant de modifier.)

Ne devinez jamais la valeur du fallthrough. Résolvez-la toujours depuis get-flag.

Étape 3 : localiser chaque valeur par défaut dans le code

Trouvez chaque endroit où le flag est évalué dans le code et, de manière critique, l'argument par défaut/fallback passé à l'appel SDK. Recherchez la clé du flag dans la base de code, puis identifiez la valeur par défaut dans chaque résultat.

• La valeur par défaut est généralement l'argument positionnel final des appels variation(...) / *Variation(...) (p. ex. boolVariation("<key>", context, <default>)).
• Les équipes enveloppent souvent le SDK. Vérifiez les couches wrapper/registre/config qui déclarent une valeur par défaut une fois par flag, les valeurs par défaut basées sur annotation ou étiquette structurelle, et les fichiers par défaut générés.

Voir Modèles de valeur par défaut SDK pour l'ensemble complet des modèles par langage et abstraction, et comment distinguer l'argument par défaut de l'argument de contexte.

Étape 4 : comparer et décider

Normalisez les deux côtés avant de comparer (voir Cas limites pour les notes JSON/nombre/type), puis :

Étape 5 : réconcilier la valeur par défaut dans le code

Mettez à jour seulement l'argument par défaut/fallback pour qu'il corresponde à la valeur attendue.

• Ne changez pas la logique d'évaluation, la ramification, ou le comportement hors chemin.
• Ne supprimez pas le flag ou son évaluation.
• Si la valeur par défaut vit dans un fichier généré, ne le modifiez pas à la main. Mettez à jour la source de vérité (le constructeur/registre/annotation) et régénérez avec la commande codegen du projet. Notez requires_generation: true dans votre résumé.

Exemple (avant puis après), valeur par défaut attendue = true :

// Avant : la panne retourne false même si la règle par défaut sert maintenant true
const enabled = await ldClient.variation('new-checkout-flow', context, false);

// Après : valeur par défaut du fallback réconciliée pour correspondre au fallthrough
const enabled = await ldClient.variation('new-checkout-flow', context, true);

La ramification if (enabled) { ... } else { ... } environnante reste inchangée.

Étape 6 : valider avant de commiter

Exécutez les vérifications configurées du projet limitées aux fichiers modifiés. Découvrez-les depuis les scripts package.json, un Makefile, AGENTS.md/CLAUDE.md/CONTRIBUTING.md, ou la config CI. Généralement : format, lint, type-check, build, et les tests pertinents.

Arrêt strict : si une vérification échoue et que vous ne pouvez pas la corriger, ne commitez ni ne poussez. Affinez votre changement à la place. Ne mettez jamais en ligne du code qui échoue format/lint/type-check/build/test.

Étape 7 : ouvrir la pull request

Seulement après que la validation passe. Utilisez references/pr-template.md. La description doit indiquer : la clé du flag, les environnements critiques vérifiés et leurs valeurs fallthrough résolues, la valeur par défaut dans le code ancienne vs nouvelle, et que seulement la valeur par défaut du fallback SDK a changé (le flag et son évaluation sont préservés).

• Suivez les conventions de contribution du dépôt (nommage de branche, style de commit). Vérifiez d'abord AGENTS.md/CLAUDE.md/CONTRIBUTING.md.
• Une valeur par défaut claire : branche fix/flag-default-drift-<flag-key>, commit fix: sync in-code default for <flag-key> to match fallthrough.

Étape 8 : produire un résumé structuré

Produisez un résumé concis avec ces champs :

flag_key:              <clé>
environments_checked:  [<env> : <valeur fallthrough résolue>, ...]
environments_diverge:  true | false
drift_detected:        true | false
old_default:           <valeur dans le code avant, ou n/a>
new_default:           <valeur attendue / valeur écrite, ou n/a>
files_modified:        [<chemins>]
pr_url:                <url ou null>
requires_generation:   true | false
notes:                 <tout ce que le relecteur doit savoir, y compris toute divergence inter-environnements>

Cas limites

Ce qu'il NE FAUT PAS faire

• Ne supprimez pas le flag ou son évaluation ; cette skill ne modifie que l'argument de valeur par défaut.
• Ne changez pas la logique d'évaluation, la ramification, ou le comportement hors chemin au-delà de la valeur par défaut du fallback.
• Ne vérifiez pas un seul environnement ; résolvez le fallthrough dans chaque environnement critique que le build sert.
• Ne réconciliez pas à un fallthrough d'environnement quand les environnements critiques divergent — une seule valeur par défaut ne peut pas satisfaire des environnements divergents, donc signalez la divergence et confirmez d'abord l'environnement autoritaire.
• Ne modifiez pas les fichiers générés à la main ; régénérez depuis la source de vérité.
• N'ouvrez pas une PR quand il n'y a pas de dérive.
• Ne devinez pas la valeur du fallthrough ; résolvez-la depuis get-flag.
• Ne mettez pas en ligne du code qui échoue format, lint, type-check, build, ou tests.

Références

• Modèles de valeur par défaut SDK : où vit la valeur par défaut du fallback par langage, wrapper, annotation, et modèle de fichier généré ; comment la trouver
• Modèle de PR : description structurée de PR pour une réconciliation de dérive
• Nettoyage de flag : si l'objectif est de supprimer entièrement le flag, non de réconcilier sa valeur par défaut
• Ciblage de flag : si l'objectif est de modifier la règle par défaut dans LaunchDarkly plutôt que dans le code