ai-shipcheck

AI Shipcheck est un scanner de préparation à la production local-first destiné aux applications largement écrites par des outils de codage IA. Son postulat : les assistants IA sont bons pour produire du code qui s'exécute, moins bons pour produire du code qui survit en production, et ils rapportent le travail comme terminé dans les deux cas. Shipcheck recherche les lacunes récurrentes et banales — une table Supabase sans row-level security, un route handler qui écrit sans vérifier l'appelant, une variable NEXT_PUBLIC_ contenant un secret, un endpoint LLM sans limite de débit ni plafond de tokens. L'utilisation tient en une seule commande : npx ai-shipcheck . Pas d'inscription, pas de clé API, pas d'envoi du code source. Il nécessite Node.js 22 ou une version plus récente. Les options incluent --fail-on (par exemple critical), --min-score, --format (json, markdown, sarif), et une sous-commande explain qui documente pourquoi une règle existe et comment la corriger. Les constats seuls ne font jamais échouer la commande ; les seuils sont optionnels, donc l'ajouter à un pipeline existant est réversible. Les codes de sortie distinguent les seuils atteints, non atteints, les erreurs d'utilisation et les erreurs internes. Ce qu'il vérifie Neuf catégories sont notées indépendamment, appuyées par 63 règles, chacune avec documentation, un fixture vulnérable, un fixture sécurisé et des tests : - Sécurité : identifiants en dur, secrets derrière NEXT_PUBLIC_, eval, injection shell, redirections ouvertes, CORS permissif, vérification TLS désactivée, cryptographie faible. - Authentification : routes d'écriture sans vérification d'autorisation, server actions non authentifiées, vérifications de privilèges uniquement côté navigateur, webhooks non vérifiés, JWT non signés, clés service-role exposées. - Base de données : tables sans row-level security, politiques USING (true), SQL construit par interpolation, suppressions non filtrées, migrations destructrices. - Fiabilité : erreurs avalées, timeouts manquants dans les chemins de requête, rejets non gérés, retries sans backoff, builds qui ignorent les erreurs de type. - Tests : absence de tests, CI sans test/build/typecheck, .only committé, code serveur sans test référent. - Observabilité : absence de monitoring d'erreurs, journalisation serveur uniquement en console, absence de React error boundary. - Performance : requêtes non bornées, I/O synchrones dans les handlers, formes N+1, imports client lourds. - Accessibilité : alt text manquant, click handlers sur des éléments non interactifs, contrôles de formulaire sans label, tabIndex positif. - Coût IA : endpoints LLM sans authentification ni limite de débit, pas de plafond de tokens, sélection du modèle contrôlée par la requête, clés de fournisseur dans le navigateur. Les stacks détectées incluent Next.js (les deux routeurs), React, Vite, Express, Fastify, Hono, NestJS, Remix, Astro, SvelteKit, Nuxt, Supabase, Firebase, Prisma, Drizzle, Mongoose, Stripe, OpenAI, Anthropic, Vercel AI SDK, LangChain, tRPC et les runners de tests courants. Les règles spécifiques à un framework ne s'exécutent que lorsque le framework est détecté, monorepos inclus. Sortie et intégration Le rapport affiche un score, un verdict, des barres par catégorie, et des constats avec fichier, ligne, règle, sévérité et confiance. Un bloqueur force NOT READY quel que soit le score. Les catégories qui ne peuvent pas être évaluées sont exclues plutôt que de recevoir un 100 gratuit. Une GitHub Action annote les constats en ligne sur le diff, écrit un rapport Markdown dans le résumé du job, produit du SARIF pour le code scanning, et fournit en sortie score, verdict, critical-count et high-count ; elle est regroupée dans un seul fichier committé afin qu'un workflow épinglé à un tag exécute exactement ce code. Confiance et périmètre L'outil n'effectue aucun appel réseau et n'envoie aucune télémétrie ; rien dans le dépôt scanné n'est exécuté — les fichiers sont lus en octets et analysés lexicalement. Les secrets sont masqués partout où ils pourraient être imprimés, les scans sont bornés et le signalent lorsqu'ils sont tronqués, et il n'y a qu'une seule dépendance d'exécution. Les limitations déclarées sont explicites : JavaScript et TypeScript uniquement ; l'analyse est lexicale plutôt que sémantique, sans raisonnement inter-fichiers ni information de type, et avec un taint tracking qui suit une valeur sur un seul saut, de sorte qu'un wrapper d'authentification personnalisé qu'il ne reconnaît pas peut produire un faux positif. Les routes Express et Fastify ne sont pas couvertes par les règles d'authentification, décrit comme la plus grande lacune connue. L'infrastructure lui est invisible, donc une table avec RLS activé dans un dashboard mais absente des migrations est signalée comme non évaluée, pas comme sûre. Un rapport propre signifie que les vérifications qu'il sait faire n'ont rien trouvé, pas que le code est correct. Les règles ont été validées contre 20 dépôts publics épinglés par commit SHA ; le tri de leur sortie aurait réduit les constats de 5 710 à 2 819 et révélé un bug de lexer affectant les numéros de ligne dans les fichiers avec des commentaires multi-lignes. La documentation couvre les règles, le contrat CLI, la configuration, le scoring, le modèle de confiance, les limitations, le modèle de menace, l'architecture, l'ajout d'une règle, la publication et la gouvernance. Licence MIT.