Comparateur de PR

Sélectionne le gagnant de la fusion parmi les PR concurrentes pour un même issue. Les portes Tier 0 éliminent les défaillances d'infrastructure ; les Tiers 1-2 évaluent la correction et la qualité ; le Tier 3 applique des bris d'égalité déterministes. Le mode dégradé gère le cas où aucune PR ne franchit les portes.

Prérequis

• CLI gh installée et authentifiée
• Un repository cible avec un issue ayant 2+ PR ouvertes

Politique du repo

Les paramètres par défaut supposent les conventions NemoClaw (CODEOWNERS de sécurité, DCO, CodeRabbit, répertoire docs/). Pour d'autres repos, éditez repo-policy.md pour surcharger.

Flux de travail

Copiez cette checklist dans votre réponse et cochez chaque étape :

Progression de la comparaison PR :
- [ ] Étape 1 : Parser l'issue (corps + commentaires) pour les critères d'acceptation
- [ ] Étape 2 : Découvrir les PR candidates (recherche d'ordre par défaut avec conditions d'arrêt)
- [ ] Étape 3 : Détecter la supersession (parser les corps de PR)
- [ ] Étape 4 : Exécuter les portes Tier 0 par PR
- [ ] Étape 5 : Exécuter les vérifications Tier 1 de correction par PR
- [ ] Étape 6 : Exécuter les vérifications Tier 2 de qualité par PR
- [ ] Étape 7 : Calculer les scores pondérés
- [ ] Étape 8 : Appliquer le classement Tier 3 (chemin heureux ou mode dégradé)
- [ ] Étape 9 : Émettre le verdict avec templates/verdict.md

Étape 1 : Parser l'issue

Extrayez les critères d'acceptation du corps de l'issue et de tous les commentaires :

gh issue view <issue-number> --json title,body,comments

Lisez chaque commentaire — les commentateurs ajoutent souvent des demandes que le corps ne capture pas.

Étape 2 : Découvrir les PR candidates

scripts/find-candidates.sh <issue-number>

Applique un ordre par défaut unique avec conditions d'arrêt.

Étape 3 : Détecter la supersession

scripts/parse-supersession.sh <pr-number-1> <pr-number-2> ...

Parse chaque corps de PR pour supersedes #N, replaces #N, closes in favor of #N, folds in #N. Une PR qui en supersède une autre gagne les égalités immédiatement.

Étape 4 : Portes Tier 0

scripts/collect-gates.sh <pr-number>
scripts/check-coderabbit-threads.sh <pr-number>

Cinq portes, toutes obligatoires. Voir checks/tier-0-gates.md pour la liste complète et l'interprétation.

Étape 5 : Correction Tier 1

Six vérifications, tous des jugements LLM. Voir checks/tier-1-correctness.md pour les exigences de preuve par vérification.

Étape 6 : Qualité Tier 2

Trois vérifications, tous des jugements LLM. Voir checks/tier-2-quality.md.

Étape 7 : Score pondéré

• Chaque passage = points complets
• Chaque jaune = demi-points
• Chaque échec = zéro
• Poids Tier 1 : 2,0× par vérification
• Poids Tier 2 : 1,0× par vérification

Étape 8 : Classement Tier 3

Branchez selon qu'une PR quelconque franchisse toutes les portes Tier 0. Voir tiebreakers.md pour les bris d'égalité du chemin heureux, le classement distance-to-ready du mode dégradé, et la matrice de couverture de comportement.

Étape 9 : Émettre le verdict

Utilisez templates/verdict.md. Chaque jugement doit porter une preuve (réf file:line, snippets de diff), chaîne de raisonnement, et le score qu'il a apporté.

Fichiers de référence

• repo-policy.md — paramètres par défaut configurables par repo cible
• checks/tier-0-gates.md — portes d'infrastructure
• checks/tier-1-correctness.md — six vérifications de correction
• checks/tier-2-quality.md — trois vérifications de qualité
• tiebreakers.md — classement Tier 3 et mode dégradé
• templates/verdict.md — modèle de sortie
• validation/backtest.md — backtestez la skill sur des cas historiques

Scripts (exécutez, ne lisez pas)

• scripts/find-candidates.sh — découverte de PR
• scripts/collect-gates.sh — évaluation des portes Tier 0
• scripts/check-coderabbit-threads.sh — résolution des threads GraphQL
• scripts/parse-supersession.sh — parsing des corps pour les références de supersession
• scripts/render-verdict.py — moteur de rendu de scorecard de verdict

Ce que cette skill NE fait PAS

Ceux-ci nécessitent une infrastructure au-delà de l'API GitHub + LLM et sont reportés aux modules v2 :

• Exécuter chaque PR contre des entrées adversariales (exécution en sandbox)
• Balayage de régression entre issues (skill séparé)
• Simulation de revert contre les PR voisines
• Intégration d'analyseur statique (CodeQL, Semgrep)