Boost déduit les conventions du projet

Ce qui se passe

Une application Laravel neuve peut consigner ses règles au fil des décisions. Une application établie, non : ses conventions vivent dans ses contrôleurs, ses modèles, ses tests, son arborescence — et dans ses absences délibérées. Quand une équipe installe Laravel Boost, ce contexte doit venir de quelque part.

Deux méthodes ont été essayées. La première, une commande Artisan boost:infer-conventions : résolveur de racine, échantillonneur de fichiers, inspecteur et cinq détecteurs écrits à la main (casse des clés d'enum, guarded contre fillable, style des query scopes, syntaxe des règles de validation), chacun rendant un score de confiance présenté dans un multiselect Laravel Prompts. Rapide, déterministe, zéro token consommé — et la branche n'a jamais été fusionnée.

Pourquoi elle a été écartée

Deux raisons, et la seconde est la vraie leçon.

Le coût d'extension d'abord : chaque nouvelle convention exigeait une classe PHP supplémentaire pour la détection, les preuves, la confiance et la sortie. La skill qui l'a remplacée couvre environ 49 dimensions réparties en 10 groupes, et ajouter une dimension coûte une ligne dans une checklist Markdown.

Le problème de la fréquence ensuite. Un projet contient des centaines de classes de migration anonymes parce que Laravel les génère ainsi. Enregistrer ce motif n'apprend rien à l'agent. Le critère retenu est explicite : une règle mérite sa place quand elle préserve un choix qu'un autre agent aurait pu manquer. « Stocker les montants en centimes entiers » change la modélisation, la validation, la sérialisation et les tests. « Utiliser des classes de migration anonymes » répète le défaut du framework.

Ce que la skill refuse d'écrire

• Ce que les outils appliquent déjà. Pint, Rector, linters et analyse statique imposent les choix mécaniques ; les répéter en prose dépense du contexte pour un travail déjà fait. Nuance retenue : si un projet préserve systématiquement une forme que Rector réécrirait, l'exception est remontée pour revue.
• Les redesigns. L'audit décrit l'application telle qu'elle est ; les preuves contradictoires restent contradictoires dans le rapport. « L'inférence de conventions est un mauvais endroit pour redessiner l'application. »
• Ce qui n'a pas trois exemples. Le seuil actuel est de trois cas cohérents sans rival sérieux, et chaque règle proposée est présentée avec les fichiers qui l'appuient. Le développeur rejette, change la portée ou réécrit ; rien n'est enregistré avant.

À l'inverse, deux catégories méritent d'être écrites : l'architecture (« la logique métier vit dans app/Actions, les contrôleurs délèguent ») et les absences délibérées (« les contrôleurs interrogent Eloquent directement, il n'y a pas de couche repository »). Une abstraction manquante fait partie de l'architecture.

Source : Laravel — Extracting AI rules from an existing codebase