build2-community/build2-review

build2-review (Vérification build2)

Résoudre ROOT (Racine)

Soit HERE le répertoire contenant ce fichier SKILL.md (chemin absolu depuis le contexte système).

ROOT est l'arbre de compétences build2. Utilisez le premier candidat dont guides/packaging-guide-review.md existe :

1. HERE/../build2 (disposition en frères : ce répertoire à côté d'une compétence build2, y compris une copie dans un répertoire de compétences de niveau utilisateur)
2. HERE/../.. (disposition imbriquée : ce répertoire sous le sous-répertoire skills/ de la compétence build2)

Si aucun n'existe, arrêtez-vous.

Tous les chemins read_file ultérieurs sont ${ROOT}/....

Ceci est une vérification locale en lecture seule. Elle existe pour détecter les problèmes de paquetage avant publication, en exécutant la même checklist qu'un relecteur cppget.org sur le dépôt. Elle ne doit jamais créer, commenter ou fusionner un ticket ou une pull request GitHub, jamais pousser une branche, jamais envoyer d'email, et jamais modifier le dépôt révisé (aucun commit, aucun tag, aucune modification de fichier, pas de bdep release, pas de bdep publish, pas de git push). Si une étape ci-dessous effectuerait une telle modification, sautez-la et transformez-la en constatation rapportée à la place. Le dépôt révisé doit sortir de cette vérification exactement comme il y est entré. Rédiger un plan pour les constatations rapportées, sans l'exécuter, ne compte pas comme une modification, voir « Mode plan » ci-dessous pour savoir quand cela s'applique.

La checklist et les critères dans ${ROOT}/guides/packaging-guide-review.md sont la source de vérité. Recopiez les éléments de la checklist. Ne paraphrasez pas les critères requis. N'inventez pas de critères de révision.

Les révisions couvrent uniquement la construction et le support de paquetage. Ignorez la qualité du code source amont, la documentation amont et le style du C/C++ amont.

Règles strictes

1. Aucun changement visible de l'extérieur : ne jamais créer, commenter ou fusionner un ticket ou une pull request GitHub, ne jamais pousser une branche, ne jamais envoyer d'email. C'est inconditionnel, cela s'applique même si l'utilisateur le demande explicitement en cours d'exécution : refusez et orientez-le vers le workflow de révision manuelle séparé (voir « Stop et demande » ci-dessous) plutôt que de le faire ici.
2. Aucune modification du dépôt révisé : aucun commit, tag ou modification de fichier, pas de git push, pas de bdep release, pas de bdep publish. Inspection uniquement (git log, git show, git diff, lecture de fichiers). Si vous devez construire ou tester quelque chose pour vérifier un élément, faites-le hors de l'arbre dans un répertoire temporaire, jamais à l'intérieur de l'arbre de travail du dépôt révisé.
3. Si un chemin local est donné, utilisez-le sur place, en lecture seule. Ne récupérez pas une autre référence, ne faites pas de stash ou de reset.
4. Si un dépôt distant ou une URL est donné, clonez-le en lecture seule dans un répertoire temporaire sous /tmp/claude/. N'utilisez jamais de dépôts distants avec capacité de poussée ou git push. Traitez le clone comme jetable.
5. Ne cochez jamais un élément de checklist sans l'avoir personnellement vérifié lors de cette exécution.
6. Le caractère bloquant ou non bloquant suit les critères du guide. En cas de doute, dites-le plutôt que de rétrograder silencieusement une erreur conceptuelle de buildfile.
7. La sortie est un rapport dans la conversation (éventuellement aussi écrit dans un fichier temporaire sous /tmp/claude/). Ne le publiez jamais à l'extérieur.

Lectures obligatoires (avant de rapporter des constatations)

Lisez ces fichiers en entier avec read_file avant de rapporter des constatations. Ne les parcourez pas superficiellement.

1. ${ROOT}/guides/packaging-guide-review.md
2. ${ROOT}/guides/packaging-guide-antipatterns.md
3. ${ROOT}/HOWTO/package-naming.md
4. ${ROOT}/guides/packaging-guide-testing.md, uniquement l'étape 9 (« Tester le paquet »). L'étape 10 (« Publier ») fusionne review dans main et est hors de portée ici, ignorez-la.

Chargez à la demande à partir de la carte à la fin. La checklist de révision initiale dans packaging-guide-review.md est la checklist que vous parcourez. Ce fichier est la seule copie.

Arguments

$ARGUMENTS est le texte après /build2-review (ou après /build2 review). Analyser dans l'ordre. La première règle correspondante gagne.

Premier jeton	Type
vide / omis	détection automatique après résolution de la cible
initial	checklist complète de soumission initiale
version	nouvelle version amont, basée sur les différences
revision	nouvelle révision de paquetage, basée sur les différences plus vérifications supplémentaires
autre chose	traiter comme <repo-or-local-path> et détecter le type automatiquement

Jetons restants : <repo-or-local-path> (URL GitHub, owner/repo, ou chemin de clone local) et <version> optionnel. Si la cible est manquante, demandez.

Rapportez le type choisi et la version à l'utilisateur avant de commencer.

Obtenir le dépôt

Si l'utilisateur a donné un chemin local, utilisez-le tel quel, en lecture seule.

Sinon, clonez en lecture seule dans un répertoire temporaire (ne poussez jamais vers ce clone, ne l'ajoutez jamais comme cible de poussée pour quoi que ce soit) :

git clone --recurse-submodules --shallow-submodules <url> /tmp/claude/<name>

Classifier

Déterminez <VERSION> à partir du champ version: du manifest (le dernier tag publié s'il y a plusieurs paquets). Déterminez le type :

Élément	Type
Pas encore de tag publié, ou la référence révisée est toujours le premier commit bdep new	initial
Un tag vX.Y.Z existe déjà et cette version est X.Y.Z+R	revision
Une version précédente a été taguée et celle-ci est une nouvelle X.Y.Z	version

Vérifiez le premier commit du dépôt (lecture seule) :

git log -p "$(git rev-list --all | tail -1)"

Ce commit doit contenir uniquement les fichiers générés par bdep new, et son message doit être exactement la ligne de commande. Enregistrez tout écart comme constatation. Ne l'ignorez pas.

Type : initial

Parcourez chaque élément de la section Checklist de révision initiale de packaging-guide-review.md par rapport au dépôt. Cochez un élément uniquement après l'avoir personnellement vérifié (arborescence, manifest, buildfiles, disposition d'installation, tests, tags). Utilisez le HOWTO/guide lié pour chaque élément plutôt que la mémoire.

Classez chaque constatation exactement comme le guide le fait :

Classe	Quand
Bloquant	haute sévérité ou impact, nombreux utilisateurs, erreur conceptuelle (mauvaises options de compilation dans les buildfiles), ou ne peut pas être corrigé plus tard sans casser la compatibilité
Non bloquant	devrait être corrigé dans une révision ou la prochaine version, n'échoue pas la vérification
Note	observation uniquement

Chargez à la demande lors de la vérification :

• noms : ${ROOT}/HOWTO/package-naming.md
• licence : ${ROOT}/guides/packaging-license.md
• résumé / README des -tests d'accompagnement : ${ROOT}/HOWTO/tests-extra-dependencies.md
• en-têtes privés : ${ROOT}/HOWTO/third-party-private-headers.md
• options de compilation : ${ROOT}/HOWTO/buildfile-compile-options.md
• ce qu'il ne faut pas faire : ${ROOT}/guides/packaging-guide-antipatterns.md
• commentaires ou notes de type journal dans les buildfiles, manifest ou READMEs (narration de processus, approche antérieure qui n'a pas fonctionné, incident en cours de route) : ${ROOT}/guides/packaging-guide-antipatterns.md, « N'utilisez pas de commentaires ou notes de type journal »

Lors de la vérification « Utilise le sous-module git et les liens symboliques pour l'amont » : exécutez également find . -type l -exec test -d {} \; -print dans chaque répertoire de paquet et confirmez que chaque résultat a une entrée symlink=dir correspondante dans le <pkg>/.gitattributes du paquet lui-même (voir ${ROOT}/guides/packaging-guide-summary.md Étape 5). git n'enregistre pas le type de lien symbolique, donc un lien symbolique de répertoire sans cette entrée casse silencieusement une extraction sur Windows. Traitez une entrée manquante comme bloquante.

Tester l'installation et la distribution

L'inspection statique de la checklist ne suffit pas. Construisez également le paquet hors de l'arbre pour détecter ce qui n'apparaît qu'au moment de la construction (en-têtes manquants ou privés atteignant l'arbre d'installation, fichiers manquants dans le graphe du buildfile, règles clean cassées). Faites-le dans un répertoire temporaire sous /tmp/claude/, jamais à l'intérieur du dépôt révisé. Suivez « Étape 9 : Tester le paquet » dans ${ROOT}/guides/packaging-guide-testing.md :

1. Cas installé : b install config.install.root=/tmp/claude/<name>-install, puis construisez et exécutez tests/ hors source par rapport à cette copie installée. Confirmez que rien d'inattendu n'a été installé (pas d'en-têtes manquants, pas d'en-têtes privés installés par erreur).
2. Distribution source : b dist config.dist.root=/tmp/claude/<name>-dist config.dist.uncommitted=true, puis dans l'archive extraite, exécutez configure, update, test et clean. Un bdep test vert seul ne suffit pas, c'est ainsi que cppget.org construit réellement le paquet.

Supprimez les deux répertoires temporaires ensuite. Enregistrez tout échec comme constatation (un paquet qui échoue à s'installer ou se distribuer correctement est normalement bloquant).

Rapport

Présentez les résultats à l'utilisateur en utilisant la même disposition de sections que le commentaire de résultat du guide, mais ne le publiez nulle part :

Problèmes bloquants :

...

Problèmes non bloquants :

...

Notes :

...

Omettre les sections vides. Si vous avez écrit une copie temporaire, mentionnez son chemin.

Type : version

Comparez la version de base (précédemment révisée) avec la version cible. Préférez un git diff <old-tag>..<new-tag> local si les deux tags sont disponibles dans le clone, sinon la vue de comparaison GitHub :

https://github.com/<owner>/<project>/compare/vOLD...vNEW

Surveillez la compatibilité au niveau de la construction : les cibles exportées renommées ou les variables de configuration sont cassantes même lorsque l'API amont est stable.

Rapportez l'un des :

1. Aucun changement substantiel de paquetage, aucun problème : dites-le clairement, aucune checklist nécessaire.
2. Aucun changement substantiel de paquetage, il y a des problèmes : listez-les directement (pas de checklist).
3. Changements substantiels de paquetage : exécutez la procédure initiale complète ci-dessus, checklist plus test d'installation et de distribution.

Type : revision

Identique à version, plus signalez-le comme constatation si l'un des éléments suivants n'est pas vérifié :

• Les changements se limitent à des corrections de bogues dans les buildfiles, manifest et fichiers de paquetage similaires.
• Les corrections source amont se limitent à des bogues critiques rétroportés de l'amont.
• Strictement rétrocompatible avec la version qu'elle remplace.
• Aucun changement structurel majeur (disposition source, noms de cibles exportés, noms de variables de configuration).

Mode plan

Cette compétence reste en lecture seule dans les deux cas, elle n'effectue jamais les corrections elle-même. Ce qui change est seulement si un plan pour les changements et améliorations requis est rédigé en parallèle du rapport.

• Si la session actuelle est en mode plan (l'assistant est censé proposer un plan d'implémentation pour approbation avant de faire des modifications, plutôt que d'agir immédiatement) : après le rapport, rédigez également un plan qui traite les constatations bloquantes et non bloquantes, puis présentez-le via le mécanisme d'approbation de plan fourni par l'environnement. Limitez le plan aux constatations bloquantes et non bloquantes, sautez les notes sauf si l'utilisateur le demande. Regroupez les corrections liées, et signalez toute modification touchant la disposition générée par bdep new, les fichiers manifest ou buildfile nécessitant une attention ou un ordre particulier.
• Sinon, suivez le flux de rapport établi ci-dessus et arrêtez-vous là. Ne rédigez, ne proposez ni ne suggérez un plan d'implémentation, les corrections sont à effectuer par l'utilisateur ou un workflow séparé.

Stop et demande

Arrêtez-vous plutôt que de deviner lorsque l'un des cas suivants est vrai :

• Vous ne pouvez pas déterminer la version ou le type.
• Vous ne pouvez pas accéder au dépôt (le clone échoue, le chemin local est invalide).
• Le premier commit n'est pas un commit bdep new et l'utilisateur n'a pas décidé comment l'enregistrer dans le rapport.
• La classification bloquant vs non bloquant n'est pas claire pour une constatation qui casserait la compatibilité.
• L'utilisateur a demandé d'ouvrir réellement le ticket/PR de révision GitHub, de fusionner quelque chose ou d'envoyer l'email à [email protected]. C'est un workflow séparé, hors de portée, que cette compétence n'exécute pas.
• L'utilisateur a demandé de créer le paquet plutôt que de le vérifier (passez à build2-package).

Carte à la demande

Besoin	Fichier
Checklist et critères	${ROOT}/guides/packaging-guide-review.md
Ce qu'il ne faut pas faire	${ROOT}/guides/packaging-guide-antipatterns.md
Noms	${ROOT}/HOWTO/package-naming.md
Licence	${ROOT}/guides/packaging-license.md
Paquets d'accompagnement	${ROOT}/HOWTO/tests-extra-dependencies.md
Création du paquet	../build2-package/SKILL.md