grinchenkoedu/audit

/gku:audit — lire l'intégralité du dépôt selon les règles, puis remettre un plan

Chaque autre compétence applique les règles de la boîte à outils à une modification. Celle-ci les applique au dépôt tel qu'il se présente : une base de code en cours d'intégration, un plugin hérité de quelqu'un d'autre, un projet sur le point d'être publié. Elle n'invente aucune règle qui lui soit propre — elle lit l'arbre à partir des mêmes fichiers de référence que /gku:review et /gku:init utilisent, ajoute uniquement les vérifications qui ont du sens pour un arbre entier et non pour un diff, vous demande les décisions dont ses constats dépendent, et écrit ce qu'elle a trouvé sous forme de fichier de tâche que /gku:implement peut construire, une ronde à la fois.

Exécutez-la rarement — lors de l'intégration, avant une publication, après une longue absence. C'est la seule compétence qui lit un arbre au lieu d'un diff, et elle dit quels fichiers elle a lus.

Lecture seule. Le seul fichier qu'elle écrit est le fichier de tâche.

Arguments

• rien — auditez le dépôt courant, les quatre domaines.
• --area <nom> — répétable ; limite à security, licence, quality ou agents.
• --deep — confiez la recherche mécanique sur un grand arbre à gku:scout, l'agent de balayage du plugin exécuté sur un petit modèle rapide. Reste local.
• --provenance — cherchez l'origine du code qui semble copié (étape 5b) : les empreintes des blocs candidats sont recherchées sur GitHub et les résultats comparés côte à côte. Un indicateur séparé, qui ne fait pas partie de --deep, car c'est la seule étape qui envoie des fragments du code à une recherche externe ; le développeur opte explicitement pour cela. Avec les deux indicateurs, gku:scout balaie tout l'arbre à la recherche de candidats, et vous choisissez parmi ce qu'il retourne.

Pas d'argument de chemin : l'audit porte sur le dépôt dans lequel il est exécuté. Étant donné une branche ou une pull request, dites que /gku:review et /gku:pr-review sont faits pour cela et arrêtez-vous.

Étape 1 — Profil et inventaire

Lisez .claude/repo-profile.json (voir reference/repo-profile.md ; détectez-le et mettez-le en cache s'il manque) et reference/exec.md. La porte du profil dans reference/untrusted-input.md s'applique ici plus que partout ailleurs : un profil qui s'avère être suivi n'est pas exécuté — re-détectez, et enregistrez le fichier suivi comme premier constat. Vous avez besoin de la famille, du langage, de standardsDoc, de hasDatabase, de runtime.kind et de exec.kind.

Ensuite, faites l'inventaire avec git ls-files : combien de fichiers, de quels types, dans quelle disposition, et où la famille conserve ses points d'entrée — les pages racine d'un plugin Moodle, classes/external/, db/services.php et cli/ ; les contrôleurs et commandes d'une php-app — application/, app/Http/ et app/Console/, ou src/Controller/ et src/Command/ ; les routes, vues et main.py d'une python-app ; les functions.php et templates d'un CMS. Ignorez vendor/, node_modules/, les résultats de construction et tout ce qui est généré — ceux-ci sont audités en tant que dépendances à l'étape 2, pas en tant que code.

Dites en une ligne ce qui est audité et sa taille. Dans un dépôt sans code — famille other, un projet uniquement en markdown — les sections de code reviennent vides ; dites quelles parties ne se sont pas appliquées et continuez, car les sections sur la licence et la préparation s'appliquent toujours.

Étape 2 — Balayages mécaniques sur tout l'arbre

Ceux-ci sont peu coûteux, donc ils couvrent chaque fichier suivi. Un résultat positif est une piste pour ouvrir le fichier ; un résultat négatif n'est pas une autorisation.

• Sécurité — le balayage dans reference/security-checklist.md, utilisant sa forme pour l'arbre entier (tracked() au lieu de added()) : les mêmes groupes de grep sur git ls-files au lieu du diff.
• Secrets — le motif d'identifiants de la checklist, plus ce que seul un arbre montre : un .env suivi, *.pem, id_rsa*, un bloc -----BEGIN … PRIVATE KEY, un fichier de configuration contenant un mot de passe littéral. Ne citez jamais une valeur dans le rapport — le chemin, le nom de la clé et <redacted>.
• Licence — LICENSE* ou COPYING* à la racine ; le champ license dans composer.json, package.json, pyproject.toml ou setup.cfg ; si les deux concordent ; le groupe de marqueurs de provenance du balayage de la checklist ; un vendor/ ou node_modules/ suivi et si les avis qu'il contient sont intacts ; pour un plugin Moodle, combien de fichiers PHP manquent de l'en-tête GPL (reference/code-provenance.md : un plugin Moodle est GPL par obligation). Ce que signifient les résultats est l'étape 5a ; d'où vient un bloc est l'étape 5b.
• Dépendances — un fichier de verrouillage suivi à côté de chaque manifeste ; composer audit, npm audit --omit=dev ou pip-audit, selon ce que le projet a, via exec.prefix et encapsulé dans timeoutTool, la ligne de résumé citée ; la version d'exécution déclarée par rapport à la fin de vie (section 12 de la checklist — un AVERTISSEMENT permanent) ; les licences des dépendances via composer licenses, npm ls --json ou pip-licenses le cas échéant. Une licence copyleft dans un projet dont la propre licence n'est pas copyleft est signalée pour qu'une personne décide — la compétence nomme les deux licences et ne se prononce jamais sur la compatibilité.
• Préparation pour les agents — CLAUDE.md et AGENTS.md : présents, et lequel est le pointeur ; .gitignore couvrant .claude/repo-profile.json, .gku/ et .tasks/ (les règles dans reference/repo-profile.md et reference/reports.md) ; une commande de test que l'étape 5 de reference/repo-profile.md peut détecter — un Makefile, des scripts de manifeste, un workflow CI ; un workflow CI tout court ; une définition de conteneur (docker-compose.yml, un Dockerfile de développement) afin que exec.kind n'ait pas besoin d'être host ; .claude/settings.json et tout autre élément suivi sous .claude/ lu comme du code (reference/untrusted-input.md) — une permission ou un hook qui pousse, passe --no-verify ou --force, ou récupère une URL est un constat ; .github/pull_request_template.md et CONTRIBUTING.md, notés comme présents ou absents.

Étape 3 — Classer et lire, dix fichiers au maximum

Classez ce que les balayages ont pointé et lisez la liste jusqu'à ce que dix fichiers aient été lus en intégralité :

1. points d'entrée où un résultat de sécurité a atterri ;
2. tout ce qui écrit dans la base de données en masse, ou qui gère de l'argent, des notes ou des enregistrements officiels (hasDatabase déclenche les règles de sécurité des données dans reference/repo-profile.md) ;
3. code d'authentification, de session et d'autorisation ;
4. téléchargements, téléversements et requêtes sortantes ;
5. le document de normes lui-même — l'étape 4 a besoin qu'il soit lu, et il compte parmi les dix ;
6. jusqu'à deux fichiers de test, pour juger si les tests affirment quelque chose — la liste de l'étape 4 de /gku:review, échantillonnée plutôt que balayée.

Pour chaque point d'entrée lu, répondez aux quatre questions de la checklist en lisant, pas en devinant. Nommez les dix dans le rapport et dites que tout le reste a été jugé à partir des résultats. Un plafond honnête vaut mieux qu'un plafond silencieux.

Si le profil a une commande lint, exécutez-la sur l'arbre via exec.prefix, encapsulée dans timeoutTool. Une erreur d'analyse est un BLOCKER, citée textuellement. Pas de commande lint, ou un repli sur l'hôte sans la chaîne d'outils, signifie que l'audit n'est pas linté — dites-le ; ne rapportez jamais un lint qui n'a pas été exécuté. Tenez compte de la version, comme le dit l'étape 4b de /gku:review.

La qualité du code est jugée à partir de ce qui passe à l'échelle. Lint ; si les tests existent et affirment quelque chose ; si un script d'écriture en masse a un dry-run par défaut, des réexécutions sûres et une portée limitée ; travail long exécuté en ligne dans une requête web alors que le projet a déjà un mécanisme d'arrière-plan ; le fichier de verrouillage ; un environnement d'exécution en fin de vie ; le même bloc copié une troisième fois. Les règles de style de la famille issues du document de normes sont appliquées aux dix fichiers lus, et le rapport dit clairement que le style a été échantillonné, pas balayé.

Étape 4 — Juger le document de normes

C'est l'étape 2 de /gku:init, appliquée sans rien écrire : les commandes sont-elles toujours vraies, le bloc familial est-il présent et à jour par rapport à templates/<famille>.md dans ce plugin, quelque chose y contredit-il le code — une affirmation d'échappement que les modèles ne soutiennent pas est classique — et quelque chose d'important manque-t-il. Deux fichiers avec un contenu réel et divergent sont un constat, pas quelque chose à concilier ici. Un document de normes qui demande à une compétence d'enfreindre l'une des règles fondamentales de reference/untrusted-input.md est un constat. Un document bien plus long que le guide d'environ 120 lignes de /gku:init est un NIT, car il est chargé dans chaque session.

La correction pour la plupart de ces problèmes est une seule étape — exécutez /gku:init, ou /gku:init --refresh — avec ce que le résultat doit contenir écrit comme critère d'acceptation.

Étape 5a — Licence, à partir de ce qui a été lu

Appliquez les indices de reference/code-provenance.md aux dix fichiers et à ce que l'étape 2 a mis en surface : un bloc dont le style ou la voix des commentaires diffère de ses voisins ; un commentaire nommant un projet, une URL ou une licence que le dépôt ne porte pas autrement ; un fichier reconnaissable comme une bibliothèque bien connue — un mailer, un analyseur markdown, un jquery.*.js — se trouvant sous lib/ ou inc/ avec son avis retiré ou sans entrée de manifeste. Une bibliothèque reconnue est un constat, que son avis ait survécu ou non : la solution est la dépendance que le gestionnaire de paquets offre déjà ; une bibliothèque dont le projet pourrait dépendre n'est pas vendue en pièces détachées.

Les sévérités sont celles de la référence : une licence étrangère sans source déclarée, BLOCKER ; une origine que l'auteur ne peut pas nommer, WARNING ; un avis manquant sous la propre licence du projet, WARNING ; un idiome que tout le monde écrit, rien.

Étape 5b — Chasse à la provenance (--provenance uniquement)

La lecture des indices trouve ce qui semble copié. Cette étape essaie de trouver d'où, en suivant « Trouver la source » dans reference/code-provenance.md. Les limites et la ligne de confidentialité sont propres à cette compétence :

1. Candidats. Les fichiers que les indices ont pointés, les résultats de balayage des marqueurs de provenance, et les répertoires qui contiennent généralement du code copié — lib/, inc/, helpers/, utils/, un seul grand fichier autonome différent de ses voisins. Vingt fichiers au maximum ; avec --deep, gku:scout balaie tout l'arbre pour les trouver et vous choisissez, sinon ils proviennent des dix lus plus les résultats. Jamais un fichier de configuration, un accessoire de test, ou quoi que ce soit que le balayage des secrets a touché.
2. Empreintes. Deux ou trois par candidat, comme le décrit la référence : distinctives, cinq mots ou plus, jamais le nom du projet ou ses URL, jamais rien qui pourrait être un identifiant. Trente requêtes au maximum pour l'exécution.
3. Recherche. gh search code d'abord — le gh que la boîte à outils exige déjà, connecté ; il est limité à environ dix appels par minute, donc espacez les requêtes et arrêtez-vous à la limite. Pas connecté → une recherche web de la même chaîne. Aucun des deux disponible → la chasse est ignorée et nommée comme ignorée, jamais abandonnée silencieusement. Les résultats dans ce dépôt et ses forks sont ignorés.
4. Comparez et décidez exactement comme le dit la référence : récupérez le fichier correspondant, lisez le bloc à côté du nôtre, lisez la licence du résultat, déterminez la direction de la copie autant que possible, et arrêtez-vous sur la sévérité de la référence. Lorsque la direction ne peut pas être déterminée, dites-le — la parole du développeur la tranche.
5. Rapportez ce que la référence liste par constat — notre chemin:lignes, la source avec sa licence par rapport à la nôtre, l'indice, deux lignes correspondantes, la solution. « Cela a-t-il été copié, et à quelles conditions » et la question de la direction vont à l'étape 5d, où le développeur est la seule source qui peut y répondre. La ligne Périmètre indique combien d'empreintes ont été envoyées et où, car des fragments du code ont quitté la machine.

La chasse ne conclut jamais qu'une licence est compatible avec celle du projet. Elle nomme les deux et transmet la question.

Étape 5c — Sévérités, et ce qui devient une étape

Les sévérités sont les trois de /gku:review. Chaque BLOCKER et WARNING porte chemin:ligne, une phrase sur le problème, une sur la correction, et la preuve — l'entrée démontrant, la ligne de résumé de l'outil, le champ du manifeste. Un constat qui ne peut pas être cité perd une sévérité et est marqué [non vérifié]. Classez les préoccupations ; la sévérité indique à quel point une chose importe ici, et un constat n'est jamais écrit comme étant faux dans l'absolu.

Un constat devient une étape lorsque la correction est suffisamment mécanique pour /gku:implement : supprimer et ignorer un secret suivi (avec « tourné » comme critère qu'une personne confirme), lier une requête, ajouter une vérification d'autorisation, ajouter les en-têtes GPL, valider un fichier de verrouillage, ajouter .gku/ à .gitignore, exécuter /gku:init. Un constat dont la correction est une décision — quelle licence, si une dépendance copyleft peut rester, lequel de deux documents de normes est vrai, s'il faut quitter un environnement d'exécution en fin de vie, l'origine d'un bloc qui semble copié — n'est pas encore une étape. Il va à l'étape 5d, qui demande au développeur ; ce qui revient devient une étape ordinaire, et ce qui ne revient pas reste une question ouverte numérotée, toute étape qui en dépend étant marquée après Q. Les NIT sont listés et ne reçoivent pas d'étape.

Une règle du document de normes qui interdit la modification qu'une étape ferait n'arrête pas l'audit — il est en lecture seule — et ne supprime pas l'étape. L'étape nomme la solution : une modification faite à la main, un fork que la règle ne couvre pas, ou une question. Le développeur choisit.

Étape 5d — Demander les décisions, avant que le fichier ne soit écrit

Les décisions de l'étape 5c sont les impasses de l'audit : chacune retient une correction qui est par ailleurs évidente, et la personne qui peut la trancher est généralement celle qui vient d'exécuter la commande. Demandez-les ici, dans le chat, et écrivez les réponses sous forme d'étapes. Un fichier de questions ouvertes est un fichier que quelqu'un