Que fait Correctif Dependabot ?

Corriger systématiquement une PR Dependabot en échec. L'utilisateur fournit un numéro de PR (ex: /dependabot-fix 42).

Cette compétence couvre six phases (A–F). Ne commencez pas à éditer le code avant la fin de la phase D. Ne plongez pas dans les journaux avant la fin de la phase B.

Configurez l'espace de travail une fois au début :

mkdir -p ./tmp && touch ./tmp/null
PR_NUM=<à partir de l'invite utilisateur>
REPO=EthicalML/ethical

Phase A — Contexte

Étape 1 · Contexte de la PR

Récupérez les métadonnées et produisez un résumé écrit d'un paragraphe de la PR (écosystème, regroupement, taille, s'il s'agit d'une mise à jour de sécurité, quels fichiers elle touche). N'ouvrez pas encore les fichiers source.

gh pr view $PR_NUM --repo $REPO --json title,body,headRefName,labels,files,mergeable,createdAt
gh pr diff $PR_NUM --repo $REPO | head -200

Identifiez :

Écosystème : npm | github-actions — ce sont les seuls deux que ce dépôt possède
Regroupement : groupé (all, all-security) contre un seul npm majeur (les majeurs sont exclus du groupe all par conception, donc chacun arrive seul)
Taille : nombre de fichiers et nombre approximatif de lignes modifiées ; pour npm, si package.json a bougé ou seulement package-lock.json
Si une dépendance modifiée peut affecter le rendu de sortie — cela décide la Phase E (voir Étape 8.5)

Étape 2 · Enquête d'erreur haut niveau

Listez les vérifications défaillantes et capturez la première et la dernière ligne d'erreur de chaque journal de job défaillant. N'investiguez pas encore leur signification — énumérez simplement les symptômes.

L'CI (.github/workflows/ci.yml) a exactement trois jobs requis : lint (ESLint + Prettier), typecheck (npm run check:ratchet), et build (la construction Astro de production en mode démo, sans FORM_ENDPOINT). Tout autre chose en rouge n'est pas une vérification requise.

gh pr checks $PR_NUM --repo $REPO

# Pour chaque vérification défaillante, récupérez l'ID du job à partir de l'URL et extrayez les journaux
gh run view --job <JOB_ID> --repo $REPO --log 2>./tmp/null \
  | grep -iE "error|exit code|##\[error\]|FAILED|assert|timed ?out" \
  | head -20 > ./tmp/pr-${PR_NUM}-symptoms.txt

La sortie doit être une liste à puces telle que :

lint : La vérification Prettier a échoué : package.json
typecheck : astro check a signalé 3 erreurs, la référence est 0
build : [vite] Rollup n'a pas pu résoudre l'importation "..."

Notez ce que l'CI ne peut pas voir. Les vérifications lint, le ratchet astro-check et une construction réussie ne disent rien sur l'apparence de la page. Ce vide est le travail de la Phase E, et c'est la partie la plus précieuse de cette compétence sur ce dépôt.

Phase B — Ingestion de contexte via sous-agents

Lancez deux ou trois sous-agents explore parallèles limités à ce que la PR touche. Ne lisez rien de cela vous-même avant — déléguez.

Étape 3 · Sous-agent Conventions

.github/copilot-instructions.md est le point d'entrée canonique unique pour les agents dans ce dépôt (les AGENTS.md et CLAUDE.md racine sont des liens symboliques vers celui-ci). Demandez au sous-agent de le lire et de retourner : le workflow de modification, ses vérifications locales, les conventions de commit/PR, et tout piège pertinent pour les chemins touchés. Dirigez-le également vers STYLES.md lorsque la PR pourrait toucher le style ou le ratchet de tokens, et vers REUSABLE.md lorsqu'une API de composant est impliquée.

Étape 4 · Sous-agent Harness

Demandez-lui de lire scripts/verify/README.md et de retourner un briefing (~40 lignes) sur le harnais de vérification local : ce que verify:dom, verify:shots, verify:parity, verify:typewriter et check:ratchet vérifient chacun, comment fonctionnent les indicateurs de thème et de fenêtre, où la sortie atterrit, et ce que le mécanisme de liste autorisée de parité est et n'est pas. Ce briefing est ce contre quoi la Phase E s'exécute.

Étape 5 · Sous-agent Codebase

Demandez-lui de produire une carte ciblée pour la zone touchée :

Quel(s) paquet(s) dans le diff sont réellement importés par src/** ou scripts/**, et où (un bump vers quelque chose que rien n'importe est une classe de risque différente d'un bump vers astro)
Les commandes de construction et de vérification (npm run build, npm run lint, npm run format:check, npm run check:ratchet)
Si le bump touche le pipeline de construction (astro, vite, @astrojs/*, pagefind, les plugins mdx/rehype/remark) ou seulement l'outillage (eslint, prettier, typescript)
Pour une PR github-actions : quels workflows changent et si un changement affecte le chemin de déploiement (.github/workflows/deploy.yml) plutôt que seulement l'CI

Les briefings des sous-agents forment ensemble le contexte de travail pour la Phase C.

Phase C — Diagnostic de cause racine approfondi

Étape 6 · Diagnostiquez

Maintenant — et seulement maintenant — plongez dans les journaux des jobs défaillants avec le contexte complet de la Phase B. Pour chaque vérification défaillante, retracez la première erreur significative à :

Une régression directe de la dépendance bumpée (exportation supprimée, changement de signature, validation plus stricte, valeur par défaut modifiée)
Un problème d'outillage transitif (une dépendance nécessitant une version de Node plus récente que celle définie dans .tool-versions ; un postinstall nécessitant un runtime plus récent ; une liaison native optionnelle non résolue)
Une fragilité préexistante exposée par un bump inoffensif (la référence astro-check, le ratchet de token -a###, ou le hash de STYLES.md qui se déclenche sur du churn de formatage)
Un aléa d'infrastructure (limitation de taux de registre, job annulé, échec réseau de npm ci)

Pour une PR groupée, diagnostiquez chaque vérification défaillante séparément — les défaillances peuvent avoir des causes indépendantes, et dans un lot, elles remontent généralement à différents paquets. Enregistrez les résultats dans ./tmp/pr-${PR_NUM}-diagnosis.md.

Phase D — Conception du correctif

Étape 6.5 · Triage du périmètre — s'agit-il d'un correctif, ou d'un problème de configuration Dependabot ?

Avant de planifier un correctif, vérifiez si la PR est dans le périmètre pour être corrigée. .github/dependabot.yml regroupe les mises à jour npm mineurs/de correctifs de routine en un seul groupe all par écosystème plus un groupe all-security, et exclut délibérément les npm majeurs du groupe all afin que chaque majeur arrive seul. Cette forme signifie deux situations de défaillance distinctes :

Une PR groupée échouant sur un seul paquet. C'est le cas courant et il est dans le périmètre. N'abandonnez pas le lot. Trouvez le paquet défaillant unique et soit corrigez le code pour celui-ci, soit épinglez ce seul paquet (une entrée dans package.json réduisant la plage, ou une entrée ignore Dependabot pour ce paquet et cette version) afin que le reste du lot puisse atterrir. Abandonner un lot vert-sauf-un jette une douzaine de bonnes mises à jour pour une mauvaise.

Déclencheurs de rejet de périmètre (un seul suffit — la PR est un problème de configuration, pas un correctif) :

Une PR de groupe unique contient ≥ 2 bumps majeurs — ce qui devrait être impossible avec la configuration de groupe npm actuelle, donc si cela se produit, la configuration elle-même a dérivé et est le vrai bug
Un majeur seul sur un paquet de niveau framework (astro, vite, @astrojs/*, typescript, eslint, prettier, preact, pagefind) qui est une véritable migration — pas un correctif, un projet
Le lot est principalement routinier mais son échec nécessite une migration sur un paquet qui ne peut pas être contourné par épinglage

Lorsque déclenché, n'essayez pas de corriger et ne fermez pas la PR vous-même — laissez-la ouverte pour le propriétaire. Au lieu de cela :

Si la cause est une dérive de configuration, préparez la correction de .github/dependabot.yml en tant que petite PR distincte (laissez-la au propriétaire pour révision et fusion). Sinon, aucun changement de configuration n'est nécessaire et la recommandation est simplement que la migration soit planifiée comme son propre travail.
Formulez la décision de rejet de périmètre en commentaire sur la PR Dependabot : expliquez pourquoi elle ne peut pas être corrigée en un seul passage, liez toute PR de configuration, et dites ce qu'une migration impliquerait. Laissez la PR ouverte — ne faites pas de pause pour une décision, ne la fermez pas.
Sautez le flux de commit de la Phase F — il n'y a pas de correctif. Le contenu du rapport se fond dans ce commentaire.

Les groupes de mises à jour de sécurité (all-security) restent groupés : les bumps de sécurité sont sensibles au temps et assez rares pour que les diviser coûte plus que cela ne sauve. Ne divisez un groupe que si un blocage concret l'y force.

Étape 7 · Plan complet

Écrivez un plan couvrant ce qui suit ; adaptez la profondeur au risque :

Section	Toujours	Si risque ≥ moyen
Cause racine	✅	✅
Fichiers attendus de changer	✅	✅
Approche du correctif (et alternatives considérées)	✅	✅
Évaluation du risque (faible/moyen/élevé)	✅	✅
Étapes de reproduction	✅	✅ (doit être exécutable)
Stratégie de test manuel	✅	✅ étendue
Plan de retour en arrière		✅
Rayon d'impact (sortie rendue / déploiement / URL)		✅

Risque ≥ moyen si une quelconque des conditions suivantes est vraie :

le bump touche le pipeline de construction (astro, vite, @astrojs/*, plugins MDX/rehype/remark, pagefind)
le correctif édite quoi que ce soit sous src/ plutôt que la configuration ou le fichier de verrouillage
le bump peut modifier le HTML émis, l'ordre CSS, le chargement des polices ou le comportement d'hydratation
un changement github-actions touche deploy.yml (un déploiement cassé est une interruption de site en direct, pas une vérification rouge)

Tout npm majeur est au moins moyen par défaut. Un majeur arrive seul précisément parce qu'il mérite d'être lu et testé par lui-même ; traitez-le avec plus de rigueur qu'un lot de même taille.

Étape 8 · Stratégie de test manuel (hiérarchisée)

Hiérarchisez l'effort par l'évaluation du risque de l'Étape 7 :

Faible (outillage uniquement) — appliquez le correctif, exécutez la porte la plus étroite pertinente (npm run lint, npm run format:check, ou npm run check:ratchet). Aucune étape de reproduction nécessaire.
Moyen (pipeline de construction ou édition src/) — d'abord reproduisez la défaillance localement sur la branche de la PR pour prouver que la régression est réelle (pas un artefact CI). Ensuite appliquez le correctif, relancez les vérifications locales complètes : npm run lint && npm run format:check && npm run check:ratchet && npm run build. Puis Phase E.
Élevé (majeurs, tout ce qui peut modifier la sortie rendue, changements de déploiement) — tout ce qui est dans moyen, plus le balayage de parité de la Phase E est obligatoire, plus npm run verify:dom:all contre la tête de la PR construite, plus npm run verify:typewriter si le héros ou les tokens de mouvement sont impliqués.

Conservez toute la sortie de travail sous ./tmp/ (gitignoré). Utilisez ./tmp/null comme puits lors de la suppression de la sortie :

npm run build 2>./tmp/null

Phase E — Parité visuelle par rapport à la base de fusion

L'CI prouve que le site se construit encore. Elle ne prouve pas que le site a toujours la même apparence. Un bump de dépendance devrait être pixel-neutre par définition — si ce n'est pas le cas, quelque chose a été rendu différemment et personne ne l'aurait vu. Cette phase est la raison pour laquelle cette compétence existe sur ce dépôt.

Aucune référence de pixel n'est commitée (scripts/verify/out/ et tmp/ sont gitignorés), donc la comparaison doit être générée en cours d'exécution : capturez la base de fusion, capturez la tête de la PR, comparez.

Étape 8.5 · Décidez de l'exécuter

Le balayage coûte environ 4 à 5 minutes par PR (deux constructions plus deux balayages de captures d'écran sur 37 routes × 2 fenêtres). Ne sautez-le que lorsque le changement ne peut pas affecter le rendu. Il est sautable lorsque toutes les conditions suivantes sont vraies :

La PR est uniquement github-actions, ou ne touche que .github/**
Aucun fichier sous src/, public/, astro.config.mjs, ou dependencies de package.json n'a changé
Le diff est confiné aux devDependencies dont la sortie n'atteint jamais dist/ (eslint*, prettier, @types/*, typescript lorsque le ratchet est inchangé)

Tout le reste — tout bump astro, vite, @astrojs/*, preact, pagefind, MDX/rehype/remark, police ou outillage CSS, et chaque npm majeur — exécute le balayage. En cas de doute, exécutez-le ; cinq minutes sont moins chères qu'une régression visuelle silencieuse sur un site en direct.

Dites explicitement dans le rapport quelle branche de cette décision a été prise et pourquoi.

Étape 9 · Capture et comparaison

Playwright n'est pas une dépendance du dépôt ; le harnais le conduit depuis un chemin de cache npx déjà câblé dans les scripts. Servez chaque construction avec un serveur statique simple.

BASE_SHA=$(git merge-base origin/master HEAD)
mkdir -p ./tmp/parity

# --- base de fusion ---
git checkout $BASE_SHA
npm ci
npm run build
cp dist/index.html ./tmp/parity/base-index.html    # empreinte de ce que nous servons
nohup npx --yes http-server dist -p 4126 --silent < ./tmp/null > ./tmp/parity/base-server.log 2>&1 &
BASE_SERVER=$!
npm run verify:shots:all
kill $BASE_SERVER
cp -R scripts/verify/out ./tmp/parity/base

# --- tête de la PR ---
gh pr checkout $PR_NUM --repo $REPO
npm ci
npm run build
cp dist/index.html ./tmp/parity/head-index.html
nohup npx --yes http-server dist -p 4126 --silent < ./tmp/null > ./tmp/parity/head-server.log 2>&1 &
HEAD_SERVER=$!
npm run verify:shots:all
kill $HEAD_SERVER
cp -R scripts/verify/out ./tmp/parity/head

# --- comparez, par fenêtre ---
npm run verify:parity -- ./tmp/parity/base/1440 ./tmp/parity/head/1440 > ./tmp/parity/1440.json
npm run verify:parity -- ./tmp/parity/base/420  ./tmp/parity/head/420  > ./tmp/parity/420.json

Le piège du dist périmé. Réutiliser le port 4126 entre deux constructions est le moyen le plus probable de produire un vert confiant et vide de sens : si l'ancien serveur n'est pas réellement mort, ou si dist n'a pas été reconstruit, le deuxième balayage photographie la première construction et la parité passe parce que vous avez comparé une construction à elle-même. Protégez-vous à chaque exécution :

Confirmez que le serveur précédent est parti avant d'en démarrer un nouveau (lsof -i :4126 ne retourne rien).
Différenciez les deux empreintes — cmp ./tmp/parity/base-index.html ./tmp/parity/head-index.html retournant "identique" pour une PR qui a changé src/ ou une dép du pipeline de construction est un signal pour ne pas faire confiance à l'exécution, pas un résultat.
Si le JSON du balayage lui-même signale compared: 0 ou que chaque route est manquante, le serveur n'était pas opérationnel ; l'exécution est nulle, pas réussie.

verify:shots écrit la sortie du thème sombre dans out/<width>/. Si un bump affecte plausiblement le thème clair différemment (outillage CSS, gestion des couleurs, émission de tokens), répétez le balayage avec --theme light, qui écrit dans out/light/<width>/ et ne peut pas écraser l'arbre sombre.

Étape 10 · Interprétez le résultat

verify-parity signale deux nombres par route, et les deux comptent

… [tronqué pour la traduction]

Correctif Dependabot

Qu'est-ce que Correctif Dependabot ?

Demander à votre IA préférée

Documentation