Paramètres Factory de LaunchDarkly

Vous utilisez une skill qui configure Factory (automatisation de code GitHub App) via le MCP LaunchDarkly, ou explique pourquoi une PR n'a pas été classifiée. Factory peut ouvrir et modifier les pull requests (auto-flagging) et peut piloter l'auto-releasing. Traitez chaque écriture comme une automatisation de production avec un rayon d'explosion.

Prérequis

Cette skill nécessite le serveur MCP LaunchDarkly hébergé à distance.

Outils MCP requis :

get-factory-settings / update-factory-settings
list-factory-github-repos (installation GitHub App — repos mappables)
list-factory-repo-settings (déjà mappés)
update-factory-repo-settings / get-factory-repo-settings / delete-factory-repo-settings

Si ces outils manquent, arrêtez-vous. N'inventez pas d'appels REST, d'IDs GitHub numériques, ou de « corrections » en devinant les paramètres.

Les paramètres Factory sont en alpha : les endpoints sous-jacents sont gérés par le flag enable-factory-settings. Si chaque outil Factory retourne 404, le compte n'est pas en alpha — prévenez l'utilisateur plutôt que de réessayer ou de revenir à REST.

Principes fondamentaux

Échouer fermé. Le diagnostic est en lecture seule. Ne changez jamais les paramètres pour « faire fonctionner la classification » sauf si l'utilisateur a confirmé cette écriture exacte après avoir vu l'état actuel vs proposé.
Les paramètres de compte sont la barrière maître. Un repo mappé ne peut pas activer une capacité que le compte a désactivée. Désactiver une capacité au niveau du compte la désactive pour chaque repo mappé. L'activer au niveau du compte permet à chaque repo mappé qui hérite (pas d'override désactivé) de commencer à automatiser les PRs.
Confirmez avant chaque écriture Factory. Patch de compte, mapping, overrides de repo, et unmap utilisent tous Confirmer avant d'écrire. Touchez uniquement les repos que l'utilisateur a nommés.
Privilèges minimaux. N'activez jamais l'auto-releasing sauf si l'utilisateur l'a explicitement demandé (cela peut déployer du code). Ne désactivez jamais approvalRequired sauf s'ils ont explicitement demandé de supprimer la barrière d'approbation. Ne mappez ni ne demmappez des repos qu'ils n'ont pas nommés. N'itérez pas sur la liste d'installation et ne mappez pas tout.
Découvrir, puis mapper. Passez owner/name. Ne demandez jamais un ID GitHub numérique. Préférez git remote de l'espace de travail actuel quand ils disent « ce repo » / « cette PR » ; si les remotes divergent (fork vs upstream), demandez lequel. owner/name se résout uniquement contre la liste d'installation GitHub App — un repo en dehors de l'installation ne peut pas être résolu ou traité, car Factory fonctionne via l'App. Un 404 disant que le repo n'est pas sur l'installation, ou que l'App n'est pas installée, est la réponse ; ne réessayez pas avec d'autres orthographes et ne cherchez pas le repo ailleurs.
projectKey au premier mapping. Requis lors de la création d'un mapping ; les mises à jour ultérieures peuvent l'omettre.
Omettez autoCleanup. Pas encore part des paramètres Factory. Ne l'envoyez jamais ; ne le copiez jamais d'une réponse dans un PATCH.
N'installez pas GitHub App via MCP. Si list-factory-github-repos dit qu'elle n'est pas installée, arrêtez-vous et dites-leur de l'installer dans l'interface LaunchDarkly.

Confirmer avant d'écrire

ARRÊTEZ. N'appelez pas update-factory-settings, update-factory-repo-settings, ou delete-factory-repo-settings jusqu'à ce que l'utilisateur ait répondu oui à la proposition dans ce tour. Un oui d'un tour antérieur, ou un vague « corrigez-le » / « allez-y » qui ne nomme pas le paramètre, n'est pas suffisant.

Lisez d'abord l'état actuel (get-factory-settings, et repo get/list si le changement est au niveau du repo).
Énoncez maintenant vs proposé, en une ou deux phrases. Incluez le rayon d'explosion. Pour un mapping, énoncez l'auto-flagging et l'auto-releasing hérités du compte (lisez get-factory-settings d'abord).
Attendez. N'incluez pas l'écriture dans le même tour d'outil que la question.

Changement de compte (tout champ sur update-factory-settings, y compris l'activation) :

L'auto-flagging est ON pour ce compte. Le désactiver pour tous les repos mappés ? L'auto-flagging des pull requests s'arrêtera jusqu'à ce qu'il soit réactivé.

L'auto-flagging est OFF pour ce compte. L'activer pour le compte ? Les repos mappés qui héritent de ce paramètre peuvent commencer à recevoir des pull requests auto-flagged.

L'approbation requise pour l'auto-flagging est ON. La désactiver ? Les PRs auto-flagged n'auraient plus besoin de cette barrière d'approbation.

Même schéma pour l'auto-releasing, et dites que l'auto-releasing peut déployer.

Mapper ou modifier un repo (update-factory-repo-settings) :

Nommez toujours les deux capacités de compte héritées dans la proposition. Les overrides omis héritent auto-flagging et auto-releasing ; ne confirmez pas un mapping qui mentionne uniquement l'auto-flagging.

launchdarkly/gonfalon n'est pas mappé. Le mapper au projet default, héritant auto-flagging de compte (ON) et auto-releasing (OFF) ? Factory peut commencer à classer et ouvrir des PRs auto-flagged dans ce repo. L'auto-releasing restera off sauf si le compte (ou un override de repo) l'active.

launchdarkly/gonfalon n'est pas mappé. Le mapper au projet default, héritant auto-flagging de compte (ON) et auto-releasing (ON) ? Factory peut commencer à auto-flagger des PRs dans ce repo et auto-releasing, ce qui peut déployer.

launchdarkly/gonfalon est mappé à default avec auto-flagging effectif ON et auto-releasing effectif OFF. Définir un override de repo désactivant l'auto-flagging pour ce repo uniquement ? L'auto-releasing reste hérité (OFF).

Unmap (delete-factory-repo-settings) :

launchdarkly/gonfalon est mappé au projet default avec auto-flagging effectif ON et auto-releasing effectif OFF. Le demmapper ? Factory arrêtera l'auto-flagging et l'auto-releasing de ce repo jusqu'à ce qu'il soit remappé.

Après confirmation, appliquez uniquement les champs de la proposition. Puis vérifiez (n'utilisez pas la vérification comme contrôle de sécurité).

Choisir un workflow

« Pourquoi Factory n'a pas classifié / auto-flaggé ma PR ? » (ou similaire) → Pourquoi ma PR n'a pas été classifiée ? en premier. N'écrivez pas de paramètres dans ce workflow.
Configurer / mapper / activer / demmapper → Configurer les paramètres.

Pourquoi ma PR n'a pas été classifiée ?

Utilisez ceci quand l'utilisateur demande pourquoi une PR n'a pas été classifiée, auto-flaggée, ou que Factory a ignoré la PR. Lecture seule. Vérifiez dans cet ordre. Arrêtez-vous à la première défaillance et dites-leur comment la corriger (puis Confirmer avant d'écrire s'ils vous demandent d'appliquer la correction).

Identifiez le repo GitHub (owner/name) à partir de l'URL PR, git remote, ou le nom qu'ils ont donné. Si vous ne pouvez pas identifier un repo, demandez. Ne diagnostiquez pas un repo différent.

L'auto-flagging est-il activé pour le compte ? get-factory-settings. Si autoFlagging.enabled est false, c'est la réponse : la barrière du compte est off, donc aucun repo ne peut auto-flag. Arrêtez-vous.
Ce repo est-il mappé à un projet ? get-factory-repo-settings avec repo: "owner/name" (ou list-factory-repo-settings et trouvez-le). Lisez le texte 404 avant de conclure : l'App n'étant pas installée, et le repo n'étant pas sur l'installation, sont des réponses différentes du repo étant installé mais non mappé. Les repos d'installation non mappés ne lancent pas Factory. Arrêtez-vous.
Ce repo override-t-il l'auto-flagging en off ? Sur la charge du repo, si l'auto-flagging enabled est false, ou enabledOverride est true tandis que enabled est false, le repo est opt-out même si le compte est on. Arrêtez-vous.

Si les trois semblent corrects (compte on, repo mappé, auto-flagging de repo effectif on) :

Ne pas basculer les paramètres pour « essayer quelque chose ».
Pointez-les vers les runbooks Factory. Ce sont des pages Confluence LaunchDarkly internes (espace PD) tandis que Factory est en alpha ; il n'y a pas encore d'URL de docs publique. La classification peut toujours échouer pour des raisons que cette surface MCP ne peut pas voir (installation GitHub App sur la mauvaise org, PR pas dans un repo installé, permissions workflow/app, règles de skip du classifier).
- Flag Classification (ODD) Runbook — le classifier lui-même : verdicts (not-suited, already-flagged), escalades, et le registre par PR qui enregistre pourquoi une PR a reçu le verdict qu'elle a reçu.
- GitHub App Runbook — l'événement PR ne parvenant jamais à Factory : scope d'installation, permissions, webhooks.
Lectures optionnelles : list-factory-github-repos pour confirmer que le repo est sur la liste d'installation ; autoFlagging.approvalRequired s'ils s'attendaient à une PR et qu'une existe mais attend l'approbation.

Configurer les paramètres

Étape 1 : Lire les paramètres actuels

get-factory-settings
list-factory-repo-settings
list-factory-github-repos (optionnel projectKey ; l'installation est au niveau du compte)

Si GitHub App n'est pas installée, arrêtez-vous.

Étape 2 : Paramètres par défaut du compte (si nécessaire)

Si un PATCH de compte est nécessaire, suivez Confirmer avant d'écrire, puis update-factory-settings avec uniquement les champs confirmés :

autoFlagging.enabled / autoFlagging.approvalRequired (l'approbation n'est valide que ici)
autoReleasing.enabled

N'envoyez pas autoCleanup. Nécessite updateFactorySettings.

Étape 3 : Mapper ou override un repository

Uniquement pour les repos que l'utilisateur a nommés. Suivez Confirmer avant d'écrire, puis update-factory-repo-settings :

Préférez repo: "owner/name".
Incluez projectKey lors de la création d'un mapping.
Overrides optionnels au niveau du repo autoFlagging / autoReleasing. Les capacités omises héritent du paramètre de compte. Un repo ne peut pas activer une capacité que le compte a désactivée.

Nécessite updateFactoryRepoSettings sur le projet mappé.

Étape 4 : Vérifier (après une écriture confirmée)

get-factory-repo-settings / get-factory-settings le cas échéant.
L'enabled effectif doit correspondre à la proposition (compte off ⇒ repo ne peut pas être on).
Les repos mappés apparaissent dans list-factory-repo-settings.

Pour demmapper : Confirmer avant d'écrire, puis delete-factory-repo-settings.

Hors de portée

Auto-cleanup
Installation GitHub App / OAuth
Vega BYOK
MCP Observability (github_repositories) — n'exigez pas un second serveur MCP juste pour mapper un repo Factory
Modifier les règles de classification, les permissions GitHub App, ou le scope d'installation org via cette skill

launchdarkly-factory-settings