Auto Repair
Comment Codexe corrige les erreurs de build à la livraison, les corrections gratuites « réessayer » et « Corriger avec l'IA », et quand passer par le chat.
Mis à jour
Sur cette page
Auto Repair, c'est Codexe qui corrige lui-même les erreurs de build ou de chargement, à partir des erreurs exactes du build. Cela se produit dans deux situations, et savoir laquelle s'applique vous indique si une correction est gratuite.
#1. Correction interne pendant la livraison (gratuite)
Pendant que Codexe vérifie un projet compilable, un build en échec ne vous parvient pas sous la forme d'un projet cassé (chaque étape, dans l'ordre). Codexe :
- lit les erreurs exactes du compilateur ou du chargement,
- recherche les vraies signatures des classes de bibliothèque concernées, dans les mêmes JAR que ceux utilisés par le build, pour que la correction corresponde à la version réelle de l'API,
- demande à un modèle de correction de ne changer que le nécessaire,
- relance le build.
Il continue pendant plusieurs tours tant que le nombre d'erreurs diminue, et s'il reste bloqué, il fait une dernière tentative avec un modèle plus puissant. Vous le voyez sous la forme Correction d'un problème… et Vérification… sur le projet.
Ce travail est à la charge de Codexe, pas à la vôtre. Il n'utilise pas vos tokens et ne compte pas comme un prompt.
#2. Les corrections que vous lancez
| Où | Bouton | Ce que ça coûte |
|---|---|---|
| Projet qui s'est terminé « à corriger » | Laisser Codexe réessayer (gratuit) | Gratuit |
| Compiler en échec, fichiers inchangés depuis la livraison | Corriger avec l'IA | Gratuit (même correction interne) |
| Compiler en échec, fichiers modifiés par vous ou par le chat | Corriger avec l'IA | Un message de chat normal (tokens) |
| Tout le reste | Décrivez le problème dans le chat | Un message de chat normal (tokens) |
Le « réessayer » gratuit est limité à une fois par projet et par jour, et à trois projets par jour par compte.
Pourquoi cette différence ? Si les fichiers sont exactement ceux que Codexe a livrés, l'échec relève de la responsabilité de Codexe. Une fois que le projet a changé, la correction est un nouveau travail sur votre version, comme n'importe quelle autre demande.
#Quand la correction s'arrête
Codexe arrête de corriger quand les erreurs cessent de diminuer, que la même erreur revient sans cesse, ou qu'une limite de temps ou d'effort est atteinte. Le projet affiche alors Codexe n'a pas pu terminer automatiquement la vérification de ce projet. Tous les fichiers sont toujours là. Consultez Projet en échec ou à corriger.
#Ce que la correction ne peut pas réparer
- Le comportement. La correction répare le code qui ne compile pas. Elle ne peut pas savoir qu'une fonctionnalité marche différemment de ce que vous vouliez ; dites-le dans le chat.
- Les problèmes d'infrastructure. Si le build n'a pas pu s'exécuter du tout (un dépôt de dépendances a expiré, le service de build était occupé), il n'y a rien à corriger. Le projet est alors marqué non vérifié et Codexe réessaie plus tard.
- Les add-ons Skript non pris en charge. Si un script a besoin d'un add-on absent du serveur de test, Codexe le signale au lieu de réécrire votre script.