WTF

Utilisez cette compétence comme audit implacable avant lancement ou avant commit pour les projets « codés à la vibe » qui bougent vite. L'objectif est de trouver des blocages concrets avant que le code ne soit expédié, pas de produire un essai générique sur les bonnes pratiques.

Mode de fonctionnement

Inspectez le repository réel avant de le juger. Commencez par git status --short, la documentation du projet, l'arborescence des fichiers, les manifestes de paquets, la configuration du framework, la configuration CI et la configuration de déploiement.
Gardez l'audit limité à la cible de l'utilisateur : branche actuelle, changements en staging, un diff de PR, ou le projet entier. En cas de doute, par défaut à l'arborescence actuelle plus les fichiers susceptibles d'affecter le déploiement/runtime.
Privilégiez la preuve sur la supposition. Liez chaque constat à un fichier, une sortie de commande ou un artefact attendu manquant.
N'affichez pas les valeurs secrètes. Si un secret est commité ou exposé, nommez le fichier et la forme de la variable/clé, mais masquez la valeur.
Si l'utilisateur vous demande de corriger les problèmes, mettez en œuvre les corrections après l'audit et vérifiez-les. Sinon, restez en mode review/audit.

Flux d'audit

Cartographier le projet
- Identifier le type d'app, le framework, le gestionnaire de paquets, le runtime, la cible de déploiement, la base de données, l'ORM, le fournisseur d'authentification, et les commandes de build/test.
- Vérifier si la racine est propre ou sale. Préserver les changements utilisateur non liés.
- Trouver les points d'entrée probables : routes d'app, routes API, workers, server actions, commandes CLI, cron jobs, migrations, schémas et fichiers de config.
Vérifier l'hygiène du repository
- Chercher les fichiers .env* committés autres que les exemples sûrs, les fichiers de base de données locaux, les logs, les répertoires de cache, les outputs de build, les artefacts générés, la couverture, les uploads temporaires, les captures d'écran, et les caches d'outils.
- Vérifier que .gitignore couvre les artefacts du framework/runtime tels que .next, dist, build, .turbo, .vercel, .wrangler, .parcel-cache, coverage, node_modules, les fichiers SQLite locaux, les logs, et les dossiers d'upload/cache.
- Utiliser git ls-files pour distinguer les junk locaux ignorés des fichiers déjà trackés par Git.
Vérifier les secrets et variables d'environnement
- Chercher les tokens, clés privées, clés API, secrets JWT, URLs de base de données, secrets webhook, identifiants cloud, et URLs de production en dur.
- Vérifier que les env vars requises sont documentées dans .env.example, la documentation de déploiement, ou la config typée. Signaler les envs requises qui sont utilisées dans le code mais non documentées.
- Vérifier les logs accidentels de secrets, en-têtes d'auth, cookies, payloads de session, ou réponses de fournisseur.
Vérifier la disponibilité de la base de données
- Identifier si l'app utilise Prisma, Drizzle, TypeORM, Sequelize, les migrations Rails, les migrations Django, Alembic, Knex, du SQL brut, ou un autre système de migration.
- Confirmer que les changements de schéma ont des migrations correspondantes et que les migrations sont committées.
- Signaler la dérive de schéma, les commandes de migration de déploiement manquantes, les migrations destructrices sans plan de backfill/rollback, les données seed requises en production, et le SQL brut qui n'est pas paramétrisé.
- Si une app avec base de données n'a pas d'ORM ou d'outil de migration, signaler cela comme un risque de lancement sauf si le repository a un processus de migration alternatif clair.
Vérifier la correction de l'app et les bases de la sécurité
- Exécuter ou inspecter les scripts lint, typecheck, test, et build disponibles quand c'est pratique.
- Examiner les limites d'auth, les routes protégées, les actions admin uniquement, la séparation serveur/client, CORS, CSRF le cas échéant, les rate limits, la validation des uploads de fichiers, les surfaces SSRF, les open redirects, et l'exécution unsafe eval/shell.
- Vérifier la gestion d'erreurs et l'observabilité : les erreurs en production ne doivent pas fuir les stack traces, secrets, ou IDs internes inutilement.
Vérifier le code mort et legacy
- Chercher les routes inutilisées, les pages/composants dupliqués, les handlers API abandonnés, les anciens feature flags, les gros blocs commentés, les notes TODO/FIXME/HACK obsolètes, les placeholders générés, le débogage console, et les dépendances inutilisées, et les chemins de données de test/démo.
- Préférer les outils conscients du repository quand disponibles : compilateur TypeScript, ESLint, depcheck, manifestes de routes de framework, outils de graphique d'imports, ou les vérifications CI existantes.
- Traiter le code mort comme une sévérité inférieure sauf s'il affecte la sécurité, la taille du déploiement, le routing, les migrations, ou le comportement visible par l'utilisateur.
Vérifier la forme du déploiement
- Inspecter les Dockerfiles, la config wrangler/vercel/netlify/cloudflare, les GitHub Actions, les scripts de release, la configuration cron, et les versions de runtime requises.
- Signaler les commandes de build en production manquantes, les commandes de gestionnaire de paquets incorrectes, les étapes de migration manquantes, les secrets attendus au build time vs runtime, les répertoires de cache montés incorrectement, et les hypothèses locales uniquement.

Commandes utiles

Adaptez les commandes au repository ; n'exécutez pas de commandes destructrices larges.

git status --short
git ls-files
rg -n --hidden --glob '!node_modules' --glob '!.git' 'AKIA|BEGIN (RSA |OPENSSH |EC )?PRIVATE KEY|DATABASE_URL|JWT_SECRET|SECRET_KEY|API_KEY|ACCESS_TOKEN|REFRESH_TOKEN|WEBHOOK_SECRET|STRIPE_SECRET|OPENAI_API_KEY|ANTHROPIC_API_KEY|PASSWORD=' .
rg -n --hidden --glob '!node_modules' --glob '!.git' 'TODO|FIXME|HACK|console\\.log|debugger|ts-ignore|eslint-disable' .

Pour les projets JavaScript/TypeScript, inspectez d'abord les scripts package.json, puis exécutez seulement les scripts existants pertinents comme npm run lint, npm run typecheck, npm test, ou npm run build.

Sévérité

P0 Blocker : exposition de secret probable, perte de données, contournement d'auth, échec de déploiement en production, migration cassée, ou corruption de données utilisateur.
P1 High : risque de lancement fort tel que documentation d'env manquante, accès à base de données unsafe, route sensible non protégée, build/test en échec, ou artefacts de cache/build trackés.
P2 Medium : problème de maintenabilité ou fiabilité susceptible de ralentir les futurs travaux, comme du code dupliqué obsolète, des tests ciblés manquants, une gestion d'erreurs faible, ou des dépendances inutilisées.
P3 Low : nettoyage ou polish utile mais non bloquant pour le lancement.

Sortie spécifique à l'hôte

Détectez les capacités de review spécifiques à l'hôte à partir des instructions système/développeur/app actives, des outils disponibles, ou de la documentation locale de l'agent. N'inférez pas le support à partir du nom du modèle seul, et n'inventez pas de pseudo-directives pour un hôte.

Codex App : pour les constats liés à un fichier et une ligne spécifiques, émettez une directive de commentaire review inline par problème :
```
::code-comment{title="[P1] Short issue title" body="Explain the concrete risk and the smallest practical fix. Redact any secret value." file="/absolute/path/to/file.ts" start=42 end=42 priority=1}
```
Utilisez les chemins de fichiers absolus, des plages de lignes serrées, et priority correspondant à la sévérité (P0/P1 = 1, P2 = 2, P3 = 3). Conservez les constats au niveau du repo, les constats de fichiers manquants, les échecs de commande, et les risques résiduels dans la liste de constats normale.
Claude Code : ne supposez pas une directive de sortie de commentaire review inline. Utilisez les constats de review normaux avec les références file:line sauf si l'environnement Claude Code actuel fournit explicitement un protocole ou outil de commentaire.
Antigravity : ne supposez pas une directive de texte portable pour les commentaires d'artefact ou inline. Si l'environnement actif expose un outil d'artefact/commentaire natif, utilisez cet outil ; sinon utilisez les constats de review normaux avec les références file:line.
Zed : ne supposez pas une directive de commentaire inline au niveau de la réponse. Zed peut afficher l'UI de review des modifications d'agent, mais les constats d'audit doivent rester dans un format de review normal sauf si l'environnement Zed actif fournit explicitement un protocole ou outil de commentaire.

Format de sortie

Commencez par les constats, ordonnés par sévérité. Pour chaque constat, incluez :

Sévérité et titre court.
Preuve : chemin de fichier, ligne, commande, ou fichier attendu manquant.
Impact : ce qui peut casser ou fuir.
Fix : la plus petite prochaine étape pratique.

Puis ajoutez :

Vérifiée : les commandes réellement exécutées et leur résultat.
Non vérifiée : les vérifications ignorées et pourquoi.
Risque résiduel : tout ce que la forme du repository vous a empêché de prouver.

wtf

WTF